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?

No. The NT scheduler works on thread level, not process level. Threads
are scheduled completely independent of their processes. This means we
yield to another thread *in any process in the system*. Which makes all
the difference, I think.

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

Yes, but you can't use signal() etc for it, you have to use
SetConsoleCtrlHandler().
Also remember that in most cases, the server will not run on a console
but as a service - I don't think you'll ever get SIGINT then.

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

The documentation of signal() clearly states:
The SIGILL, SIGSEGV, and SIGTERM signals are not generated under Windows
NT. They are included for ANSI compatibility.
SIGINT is not supported for any Win32 application

Which leaves us with just SIGFPE and SIGABRT.

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

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

Otherwise, we just have to test. I'll see if I can cook something up
during the weekend unless someone beats me to it (or better yet, finds
the docs).

//Magnus