Re: Signals on Win32 (yet again)

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Signals on Win32 (yet again)
Date: 2003-12-20 10:13:45
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE171581@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32


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

The system will schedule a thread of equal priority *in any process*.
Which means another backend, or even Solitaire (I beleive it doesn't
change thread priorities) can be scheduled. (meaning we give up our
timeslice, I may have been a bit unclear about that in my first mail)

If we go with WFSO() in the main thread for the event sent from the
other process, then the sending backends end up blocking until we
actually pick up the signal. I think we're much better off with a
separate thread that picks it up and queues a user APC for the main
thread.

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

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 and use sleep time of 0 instead? That will return immidiatly
(after going into kernel mode and back, of course), without giving up
the quantum. Then there is always WaitForSingleObjectEx() which will
also schedule APCs.

I definitly think we need to pick up the signals on a different thread,
so the sending backend can get out fast. But then we can use several
different methods to signal the main thread, assuming we do polling:
1) UserAPCs with either SleepEx() or WaitForSingleObjectEx()
2) An anonymous event that is checked with WaitForSingleObject()
3) Simply using an interlocked DWORD variable. The downside of this is
that it's not Wait..():able, so we can *only* check this one. Both (1)
and (2) lends us to the possibility to wake up from a lock or similar if
the lock is implemented using a waitable object (mutex, semaphore, event
etc).

//Magnus

Responses

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Magnus Hagander 2003-12-20 10:23:41 Re: Signals on Win32 (was RE: [HACKERS] [PATCHES] fork/exec patch)
Previous Message Andrew Dunstan 2003-12-19 21:56:36 Re: Signals on Win32 (yet again)