From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | pgsql-hackers-win32 <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: Signals on Win32 (yet again) |
Date: | 2003-12-19 21:56:36 |
Message-ID: | 3FE37414.50505@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2003-12-20 10:13:45 | Re: Signals on Win32 (yet again) |
Previous Message | Merlin Moncure | 2003-12-19 21:11:43 | Re: Signals on Win32 (yet again) |