Skip site navigation (1) Skip section navigation (2)

Re: Signals on Win32 (yet again)

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: (view raw, whole thread or download thread mbox)
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 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

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.



In response to

pgsql-hackers-win32 by date

Next:From: Magnus HaganderDate: 2003-12-20 10:13:45
Subject: Re: Signals on Win32 (yet again)
Previous:From: Merlin MoncureDate: 2003-12-19 21:11:43
Subject: Re: Signals on Win32 (yet again)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group