Re: Win32 signal code - first try

> > Looking at this code, I'm thinking we can probably do away with the
> critical section alltogether. All that code now executes on
> the main thread. Does this seem correct?
>
> I've only given the code a superficial look, but I agree.
>
> A few comments.
>
> Firstly, I think the WaitForMultipleObjectsEx call in
> __pg_poll_signals is bogus. You're probably after
> SleepEx(0,TRUE), or something of the like.

No, absolutely not. It's supposed to be bogus :-) SleepEx() will give up
the remainder of the threads quantum to another thread. This means the
call often takes as much as 10ms to complete, which is *not* good if we
poll it in a loop somewhere performance critical.

> Secondly, in your pg_signal_apc, you ignore SIG_DFL handling.
> I actually think we'll need to keep a list of the default
> function calls for each type of signal, and call those
> functions (instead of ignoring the call).
Hmm. Yeah, that might be necessary.


> The rationale for this thinking is that, whilst the current
> code seems to be able to handle interprocess signals within
> the postmaster/postgres system nicely, all signals that are
> raised as a result of process execution (eg. SIGABRT, SIGFPE,
> ...) and those that come externally (eg. SIGINT from a Ctrl-C
> at the command line) will need to be caught in a dummy
> handler which makes a call to pg_queue_signal (note that we
> can't just use pg_queue_signal as the dummy handler, as I
> think this dummy handler will also need to reset itself as
> the signal handler for all signals other than SIGFPE).

Hmm. Of all signals, only SIGFPE and SIGABRT may be generated (since
we're no NT - in 9x SIGINT can be called, but we don't support that
anyway).
Will SIGABRT ever be called, really? Or can we ignore that one too?

As for pg_queue_signal:ing them - this one makes a system call
(QueueUserAPC). We are explicitly told *not* to make system calls inside
signal handlers in the docs. We probably need to handle this one with
just setting a variable to 1.

> [In other words, when a SIGFPE occurs, then we'll catch it,
> and queue an APC for it. If, for instance,
> FloatExceptionHandler is set as the handler, it'll get
> called, or if SIGDFL is set, then we'll terminate.]
>
> Lastly, how will this code play with the setjmp/longjmp
> calls? Specifically, can we make a longjmp out of a APC, as
> will occur when, for instance, a query is cancelled? This is
> the only thing that's troubling me.

Ehh. That is a good question. Can't find any documentation at all about
it. Since it's not listed as a restriction (which they are on other
places), I'd assume it's safe.

(The docs clearly state we cannot use longjmp from any other signal
handlers than FPE in the CRT, though - but we don't use those. Are you
sure that is allowed on other platforms?)


//Magnus