From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: Signals on Win32 (yet again) |
Date: | 2003-12-19 20:48:42 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE2A698B@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
>>Maybe. I'm not quite convinced of that yet - we can SleepEx with
>>a very small timeout, no? There must be a few critical places the
>>call could be made, which would in effect just delay delivery of
>>the signal for a very short time to some convenient sequence point.
>
>FWIW that method gets my vote - calling SleepEx(0) in some critical
>places; I believe that will yield the CPU but not wait any time (so if
>nothing else wants the CPU and there aren't any procedures that need
>calling then it amounts to a no-op).
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
done.
I agree that that one is probably the best one, if it can be done at a
limited number of places. If we need to put hundreds of SleepEx()es int
ehre, that's just too much. I was under the impression that this was the
case, but perhaps we just need to research that line a bit more.
I guess you'd also have to modify the lock manager in some way to make
it enter alertable state when waiting for a lock from a different
process, but that sholdn't be too hard. Haven't looked at all on that
code.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2003-12-19 21:11:43 | Re: Signals on Win32 (yet again) |
Previous Message | Joseph S. Barrera III | 2003-12-19 20:48:23 | Re: Signals on Win32 (yet again) |