Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

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


pgsql-hackers-win32 by date

Next:From: Merlin MoncureDate: 2003-12-19 21:11:43
Subject: Re: Signals on Win32 (yet again)
Previous:From: Joseph S. Barrera IIIDate: 2003-12-19 20:48:23
Subject: Re: Signals on Win32 (yet again)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group