Re: Win32 signal code - first try

Magnus Hagander wrote:
> That should be safe, IMHO. I was looking at getting rid of the
"Everyone
> else" part, I'd like to avoid having to create our own security
> descriptors if possible. If we want to be NT4 compatible, we can't use
> the "easy" functinos to build them. Nor can we use ATL, since we are
in
> C and not C++.

hm. maybe this needs some more thought. I don't know much about NT
security unfortunately.

> > 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. I could be way off in left field
here, but what I'm looking for is for someone to confirm that signals
can be received when a backend is waiting for a command (perhaps a
timeout has to be inserted?).

> Looking at your security question above, it could possibly be an issue
> if someone in the "everyone else" group connected with read access
only,
> and never sent anything. Which would be avoided with the separate
thread
> doing the read as well.

Well, my instincts are to leave the ReadFile where it is unless there is
no other way. Reading the signals from the file (pipe) is by nature a
synchronous operation.

> > I suggest reconsidering an event managed from within the main
> > backend thread to do signal blocking, in combination with the
> > bitmask you guys suggested to do filtering.
> Why is this necessary, specifically? I'm not fully in on that :-) As
> long as the bitmask of blocked signals (and queued ones) are protected
> with a crit sect?

The answer is that this keeps us from having to keep track of 'queued'
signals...the OS does this for us. We only have to maintain a list of
pending signals to potentially block multiple signals of the same type.
Postgres has two modes of operation, 'shields up' and 'shields down'.
Inside PG_SETMASK, we set the event flag to 'not signalled', meaning
pg_queue_signal must check the blockmask first, and if the signal is
blocked, stall the signal through the event until it is let go
(PG_SETMASK(&UnBlockSig);).

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.

Merlin