Re: Signals on Win32 (yet again)

Merlin Moncure wrote:

>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.
>
>

If we catch the events in the main thread then there is nothing else to
yield to. If we use a separate thread to catch them then it should call
WaitForSingleObject instead of SleepEx, ISTM. In any case, this couldn't
be handled by appropriate setting of thread priorities?

>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).
>
>
>

On Unix IIRC you should not assume that you will get a signal more than
once. If 2 signals are generated before the receiving process catches
one, it might only see the signal once. That's why it is common to see a
loop in a SIGCHLD handler, to catch all the children that might have died.

cheers

andrew