Re: Signals on Win32 (yet again) - Mailing list pgsql-hackers-win32
From | Magnus Hagander |
---|---|
Subject | Re: Signals on Win32 (yet again) |
Date | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE171581@algol.sollentuna.se Whole thread Raw |
In response to | Signals on Win32 (yet again) ("Magnus Hagander" <mha@sollentuna.net>) |
Responses |
Re: Signals on Win32 (yet again)
|
List | 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
pgsql-hackers-win32 by date: