Re: Signals on Win32 (yet again)

> 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