Re: Signals on Win32 (yet again)

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

Browse pgsql-hackers-win32 by date

  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)