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

Re: Win32 signal code - first try

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>
Cc: "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>,"pgsql-hackers-win32" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Win32 signal code - first try
Date: 2004-01-12 15:29:23
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE2A6AE1@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-hackers-win32
> > > 2. How does a sleeping backend (waiting on command) get 
> interrupted 
> > > so that it handles a signal?
> > My idea was by using WaitFor..Ex() with alertable=true.
> 
> Yes, this fine for polling, but what about when the backend 
> is *sleeping*?  As I understand the backend main processing 
> loop, (and my understanding is far from complete...) the 
> backend waits on 'read from socket' when it is not doing 
> anything.  Correct me if I'm wrong, but this is not 
> interruptible from an APC. 
It is if you use WaitForMultipleObjectsEx(). Or if you use
WSAEventSelect() and then WaitForSingleObjectEx() on the event (this
emulates select() the closest)

<snip>


> This is a vast simplification of the handling that takes 
> advantage of two properties of postgres's signal handling:
> 
> 1. Signals are manipulated as a group, the blockmask is never 
> manipulated directly in code. 2. The signal group does not 
> chang without being brought down first.
> 
> As long as these two properties are true, we can use a single 
> event to handle all blocked (queued) signals.  To my way of 
> thinking, this is a much cleaner implementation and follows 
> pg's overall signaling model. It will simplify the code that 
> executes when the blockmask comes down.

Ok. Given this simplifications, we can use a single event, yes :-)
So basically our polling would be:

if (WaitForSingleObject(hSignalDeliveryEvent,0) == WAIT_OBJECT_0) {
  DeliverSignals();
}

right?

If we are uncertain about delivering signals on an APC (with longjmp
considerations etc), we could even just do our QueueUserAPC() on a
function that does nothing at all. This will break any Wait..Ex() call
and then we can handle the actual signal in our polling routine. That
way we *always* know when our signals will run. We only use the
QueueUserAPC() to wake up the WAit. The other option is to always use
WaitForMultiple..() and explicitly check for the signal event, but that
would be larger code changes.


//Magnus

pgsql-hackers-win32 by date

Next:From: Merlin MoncureDate: 2004-01-12 15:46:56
Subject: Re: Win32 signal code - first try
Previous:From: Merlin MoncureDate: 2004-01-12 15:19:47
Subject: Re: Win32 signal code - first try

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