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

In any case, getting back to the original point, your
WaitForMultipleObjectEx call as written returns 0xFFFFFFFF, which clearly
indicates it is in error. If you don't want to use SleepEx (which, I really
think will be ok), you'll need come up with some other alternative. The
obvious one is to issue a WaitFor* on a dummy handle which never gets
signalled, but, between that and SleepEx, well, you get the picture :-)

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

Actually, you really can signal for it. And I am familiar with this line of
the docs:

"Note SIGINT is not supported for any Win32 application including Windows NT
and Windows 95. When a CTRL+C interrupt occurs, Win32 operating systems
generate a new thread to specifically handle that interrupt. This can cause
a single-thread application such as UNIX, to become multithreaded, resulting
in unexpected behavior."

By "not supported", it means, not supported in the usual sense of signal
(ie. interrupt and begin execution at the signal point). However, if you set
up a signal handler for SIGINT, that new thread which runs will run the
specified handler. Try a 10 line test program for yourself if you like...
However, this is all moot and a bit OT.

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

In any case, I still think it'd be nice to grab Ctrl-Cs with a
SetConsoleCtrlHandler, but we are getting ahead of ourselves :-) [BTW, I'm
nearly always running postgres from a console]

> 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

Again, not generated, but can be raised. But, like I said, this is all a bit
moot, as the only way to raise are via an in-process raise() call, and such
raise calls would end up being routed through your signal handling code
anyway. As I said, just for completeness...

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

Cool!

One final comment, having had a chance to go through the code a bit more
thoroughly. Just wondering if the logic for signal blocking is correct.
Under Unix, IIRC, if a signal is blocked when raised, it will (might?) be
delivered when that sigmask is unblocked. In the current implementation, it
looks as though blocked signals will be forever lost. If I'm right in my
recollection, we'll need some way to requeue the APC (which might be
non-trivial).

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>