Re: Win32 signal code - first try

Magnus Hagander writes:
> > 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.

I disagree. The documentation says that this is true only if there is
another thread (presumably, given the context of the doc, in the same
process) that is of equal priority and is ready to run. We'll only have
another thread, the pg_signal_thread_proc, and it'll be waiting in ReadFile
99.9% of the time, right?

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

[aside: you can raise + catch SIGINTs under NT, but a new thread gets
created to handle the call]

For completeness/future-proofing, I still think we ought to wrap whatever
signals can be generated under Win32 (which, from memory, are SIGABRT,
SIGFPE, SIGILL???, SIGINT, SIGSEGV, and SIGTERM).

For Ctrl-C at the command line, we can setup a SetConsoleCtrlHandler, and
on-call to pg_queue_signal.

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

[sigh] Good point...

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

I'd assume it is safe too, but that's not a safe assumption. :-)

> (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?)

I sure hope so. Every postgres on the planet currently does this. But yeah,
knowing this restriction in the Win32 signal handlers was what prompted my
query re: APCs. We'll need a definitive answer on this. I'll see if I can
dig anything up...

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>