Magnus Hagander said:
>>>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
>>WaitForSingleObject instead of SleepEx, ISTM. In any case,
>>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)
Ahh. OK, I understand now.
> 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
Given the above I agree at least that the event catching should be in a
If the handlers have thread safety issues one way could be have the event-
catching thread just set a flag and then check for it in the main thread,
which is a very common model for signal processing.
In response to
pgsql-hackers-win32 by date
|Next:||From: Claudio Natoli||Date: 2003-12-21 02:54:05|
|Subject: Re: Signals on Win32 (yet again)|
|Previous:||From: Magnus Hagander||Date: 2003-12-20 10:23:41|
|Subject: Re: Signals on Win32 (was RE: [HACKERS] [PATCHES] fork/exec patch)|