From: nobu.nokada@...
Date: 2002-04-11T00:05:09+09:00
Subject: Re: File change notification?

Hi,

At Fri, 5 Apr 2002 01:24:10 +0900,
QUEISSER,ANDREW (HP-Corvallis,ex1) <andrew_queisser@hp.com> wrote:
> > > For future refinement I have one follow-on question: can I build
> > > an extension DLL that creates it's own NT thread which would block
> > > on the change notification handle? Can the NT thread signal a
> > > blocked Ruby thread waiting on a mutex? I suppose the answers must
> > > be 'yes' but I'm not sure if I'm overlooking something.
> > 
> > "Yes" for first question, and "not impossible but difficult"
> > for next one.  Now win32(mswin32 and mingw32) ruby uses
> > select() in Winsock2, but it can use socket handle only, so
> > normal win32 thread synchronization mechanisms can't be used.

Sorry, Ruby uses Winsock not Winsock2 right now.

> Not sure I understand. What's the connection between the select()
> and the ability to wake up a Ruby thread? Or is it fundamentally
> difficult to have one Win32 thread communicate with the main Ruby
> thread?

First, all Ruby threads must run in one Win32 thread, and you
can use win32_main_context() to let another Win32 thread to
communicate with Ruby running in the main Win32 thread.  This
will almost work without other Ruby threads.

However, in the multi-threaded case, Ruby sleeps or waits I/O
with select() and it doesn't accept other than socket handles
(win32_main_context() uses Win32 Event handle to interrupt to
WaitForMultipleObjects() API), so you can't wake up Ruby thread
from another Win32 thread.

It may be better to rewrite wait_events() and select() with
WSAWaitForMultipleEvents() using Winsock2.  You can find the
code by searching USE_INTERRUPT_WINSOCK in win32/win32.c.

-- 
Nobu Nakada