Re: signals on windows

here's what I was going to put into initdb.c for signal handling -
comments welcome - as I think about it more I'm strongly leaning to the
"set a flag" solution - we'd check for the flag before outputting "ok"
in various places.

cheers

andrew

/*
* signal handler in case we are interrupted.
*
* The Windows runtime docs at
* http://msdn.microsoft.com/library/en-us/vclib/html/_crt_signal.asp
* specifically forbid a number of things being done from a signal handler,
* most of which we do :-) (specifically, we do IO, mem allocation and
system
* calls). Also note the behaviour of Windows with SIGINT, which says this:
* Note SIGINT is not supported for any Win32 application, including
* Windows 98/Me and Windows NT/2000/XP. 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.
* I have no idea how to handle this. (Strange they call UNIX an
application!)
* So this will need some testing on Windows.
* One alternative might be to set a flag that we periodically check for.
*
*/

static void
trapsig(int signum)
{
fputs("Caught Signal.\n",stderr);
exit_nicely();
}

[snip]

#ifdef SIGHUP
pqsignal(SIGHUP,trapsig);
#endif
#ifdef SIGINT
pgsignal(SIGINT,trapsig);
#endif
#ifdef SIGQUIT
pgsignal(SIGQUIT,trapsig);
#endif
#ifdef SIGTERM
pgsignal(SIGTERM,trapsig);
#endif

Andrew Dunstan wrote:
>
> here's what I was going to put into initdb.c for signal handling -
> comments welcome - as I think about it more I'm strongly leaning to the
> "set a flag" solution - we'd check for the flag before outputting "ok"
> in various places.

I assume we will have some sort of signals in Win32, though their
delivery will be probably via shared memory flags, so that might not
work for initdb. The flag solution may be best for initdb.

---------------------------------------------------------------------------

>
> cheers
>
> andrew
>
> /*
> * signal handler in case we are interrupted.
> *
> * The Windows runtime docs at
> * http://msdn.microsoft.com/library/en-us/vclib/html/_crt_signal.asp
> * specifically forbid a number of things being done from a signal handler,
> * most of which we do :-) (specifically, we do IO, mem allocation and
> system
> * calls). Also note the behaviour of Windows with SIGINT, which says this:
> * Note SIGINT is not supported for any Win32 application, including
> * Windows 98/Me and Windows NT/2000/XP. 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.
> * I have no idea how to handle this. (Strange they call UNIX an
> application!)
> * So this will need some testing on Windows.
> * One alternative might be to set a flag that we periodically check for.
> *
> */
>
> static void
> trapsig(int signum)
> {
> fputs("Caught Signal.\n",stderr);
> exit_nicely();
> }
>
> [snip]
>
> #ifdef SIGHUP
> pqsignal(SIGHUP,trapsig);
> #endif
> #ifdef SIGINT
> pgsignal(SIGINT,trapsig);
> #endif
> #ifdef SIGQUIT
> pgsignal(SIGQUIT,trapsig);
> #endif
> #ifdef SIGTERM
> pgsignal(SIGTERM,trapsig);
> #endif
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Hi,
This MS documentation looks like it's slightly retro. I've been trying
to decypher this stuff myself for a decade, so I might offer some points:.

>Andrew Dunstan wrote:
>
>
>> * Note SIGINT is not supported for any Win32 application, including
>>* Windows 98/Me and Windows NT/2000/XP.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.
>>
Odd. First they say it's not supported, then they go on to define how it
works. Probably what they mean is that Win32 _GUI_ applications have no
way to have receive SIGINT from Ctrl+C, because that's handled as just
another keystroke by the GUI system (sometimes you'll see the older
documentation use Win32 as a term implying GUI). Win32 console apps
appear to respond to Ctrl+C much like unices do.

Since Win32 will create a new thread for you, if you prepare your app
for that, I don't see a reason you can't make pure Win32 system calls
from that thread. You mainly want to be careful to not confuse a
single-threaded C runtime. Note that the doc
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_signal.asp
says not to "use any function that generates a system call (e.g.,
*_getcwd*, *time*)", it doesn't say not to make system calls themselves.
It doesn't look like a "signal" is not a kernel primitive on NT, it's a
feature of the CRT implemented in userspace with lower-level OS primitives.

>> * I have no idea how to handle this. (Strange they call UNIX an
>>application!)
>> * So this will need some testing on Windows.
>> * One alternative might be to set a flag that we periodically check for.
>>
A kernel Event
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createevent.asp)
is a common tool for this sort of thing.

- Marsh

Thanks. I think for now the most portable and simple thing we can do in
initdb is simply to have the signal handler set a flag that is checked for
every so often. That's what my current code does. See
http://www.dunslane.net/~andrew/initdb.c

If you think this won't work on Windows please let me know - I'm quite
confident it will work elsewhere.

cheers

andrew

----- Original Message -----
From: "Marsh Ray" <marsh-pg(at)mysteray(dot)com>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>; "pgsql-hackers-win32"
<pgsql-hackers-win32(at)postgresql(dot)org>
Sent: Friday, October 10, 2003 12:09 AM
Subject: Re: [pgsql-hackers-win32] signals on windows

> Hi,
> This MS documentation looks like it's slightly retro. I've been trying
> to decypher this stuff myself for a decade, so I might offer some points:.
>
> >Andrew Dunstan wrote:
> >
> >
> >> * Note SIGINT is not supported for any Win32 application, including
> >>* Windows 98/Me and Windows NT/2000/XP.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.
> >>
> Odd. First they say it's not supported, then they go on to define how it
> works. Probably what they mean is that Win32 _GUI_ applications have no
> way to have receive SIGINT from Ctrl+C, because that's handled as just
> another keystroke by the GUI system (sometimes you'll see the older
> documentation use Win32 as a term implying GUI). Win32 console apps
> appear to respond to Ctrl+C much like unices do.
>
> Since Win32 will create a new thread for you, if you prepare your app
> for that, I don't see a reason you can't make pure Win32 system calls
> from that thread. You mainly want to be careful to not confuse a
> single-threaded C runtime. Note that the doc
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_CRT_signal.asp
> says not to "use any function that generates a system call (e.g.,
> *_getcwd*, *time*)", it doesn't say not to make system calls themselves.
> It doesn't look like a "signal" is not a kernel primitive on NT, it's a
> feature of the CRT implemented in userspace with lower-level OS
primitives.
>
> >> * I have no idea how to handle this. (Strange they call UNIX an
> >>application!)
> >> * So this will need some testing on Windows.
> >> * One alternative might be to set a flag that we periodically check
for.
> >>
> A kernel Event
>
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba
se/createevent.asp)
> is a common tool for this sort of thing.
>
> - Marsh