Re: Win32 signal code - first try

I think we should start thinking more about how this code will be
integrated into the source as a whole. Couple of outstanding issues:

1. Are there any security issues related to the pipe server...can we
guarantee that incoming signals are coming from the postmaster?

2. How does a sleeping backend (waiting on command) get interrupted so
that it handles a signal?

Also, from over the weekend:

1. I vote not to use PulseEvent...there is almost always a better
solution
2. I think readfile should stay on the pipe server main thread but the
WriteFile should get moved. I see no advantage to reading the incoming
signals asynchronously and it could cause some problems.
3. This can probably be done using Critical Sections, not Mutexes.
4. I like the idea of the bitmask to filter multiple signals of same
type. Adjustment to pipe server to create new thread was made for this
reason. This filter should be applied to make handling go as close to
spec as possible, maybe a little research is in order here.

Also, remember that all signal handling in postgres goes through an
interface (pgsignal.c) that handles implementation specific details.
These interface routines are a very convenient place to put OS specific
calls without dirtying the code base.

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.

Here is pg_queue_signal in pseudo code:

pg_queue_signal(int signum) {

if (SignalIsAllowedToBeBlocked) /* check signal vs. block mask */
{
if (SignalIsAlreadyPending)
{
return;
}
else
{
SetPendingFlagForSignal();
WaitForSingleObject(SignalBlockHandle, INFINATE);
QueueUserAPC(...);
}
}
else
{
/* do we have to check the pending bit filter here? */
QueueUserAPC(...);
}

The signal filter is reset as soon as a signal handler routine is
entered.

Merlin