Re: Signals on Win32 (yet again)

Magnus Hagander wrote:
> Correct, SleepEx(0) with nothing to do will only incur the cost of a
> switch to kernel mode and back. If other threads are runnable at the
> same priority level, they will get scheduled, but no actual sleeping
is
> done.

Is that 100% correct?  The way I read MSDN docs for SleepEx() is that if
there is at least one other thread running at any priority in the same
process, the thread that calls SleepEx() gives up the remainder of its
timeslice to that thread.  This could have performance implications if
other threads have to be created for some reason.

I think WaitForSingleObject(INFINITE) (in the backend thread) is more
appropriate.  This will return immediately if the object is signaled but
unlike SleepEx() does not give up the remainder of its timeslice.  We
can turn on the event when the backend starts up and leave it on until a
signal thread turns it off (meaning, the backend must stop and take
another action).  Also, the signal processing will occur in the main
thread, not the worker thread.  As soon as the backend enters the signal
handling routine, it resets the event status to 'on' meaning it can
accept more signal interrupts.  In the rare case that signals stack up,
a FIFO stack could hold them (is this allowed in unix? I honestly don't
know).

Merlin