Re: Win32 signal code - first try

> > > 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