> 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