Re: Signals on Win32 (yet again)

["Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>]

> The system will schedule a thread of equal priority *in any process*.
> Which means another backend, or even Solitaire (I beleive it doesn't
[...]

OK, that is helpful.  SleepEx is only appropriate when you really want
your thread to sleep, not when you want to signaling.  SleepEx is used
mostly for Asynch I/O while waiting for File I/O to complete.

> >>I think WaitForSingleObject(INFINITE) (in the backend thread) is
more
> >>appropriate.  
[...]

> I'm not quite following this part. You mean use the event "backwards",
> in the way that it is almost always signalled? Why not use it in the
> normal way 
[...]

My thought was to execute the signal in the worker thread while
suspending the main thread.  Then I realized an APC is simply a more
direct way to do this.  If we go the polling approach instead of the
kernel driver approach, then IMO QueueUserAPC is the best route, with a
timeout of 0 as you specified.

> I definitly think we need to pick up the signals on a different
thread,
> so the sending backend can get out fast. 

Yes.  

> different methods to signal the main thread, assuming we do polling:
> 1) UserAPCs with either SleepEx() or WaitForSingleObjectEx()

Yes, but with WFSO, not SleepEx().

> 2) An anonymous event that is checked with WaitForSingleObject()

I don't think there is a truly elegant solution with this approach.  At
minimum, after every 'poll' there has to be 

if (0 != ret)

which should be avoided, if possible.  There are some other ways to work
it out, none AFAICT as elegant as QueueUserAPC.

> Simply using an interlocked DWORD variable
I Don't think this is a good idea.

Has a final decision been made wrt the kernel driver approach?  ISTM
this should be fully discounted before going with a regular
synchronization model.  I've never seen one in action, though.

Merlin