From: | "Andrew Dunstan" <andrew(at)dunslane(dot)net> |
---|---|
To: | <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: Signals on Win32 (yet again) |
Date: | 2003-12-20 12:55:31 |
Message-ID: | 2261.24.211.141.25.1071924931.squirrel@www.dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
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
>>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)
>
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
> thread.
>
Given the above I agree at least that the event catching should be in a
separate thread.
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Natoli | 2003-12-21 02:54:05 | Re: Signals on Win32 (yet again) |
Previous Message | Magnus Hagander | 2003-12-20 10:23:41 | Re: Signals on Win32 (was RE: [HACKERS] [PATCHES] fork/exec patch) |