Обсуждение: signals on windows

Поиск
Список
Период
Сортировка

signals on windows

От
Andrew Dunstan
Дата:
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





Re: signals on windows

От
Bruce Momjian
Дата:
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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: signals on windows

От
Marsh Ray
Дата:
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


Re: signals on windows

От
"Andrew Dunstan"
Дата:
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@mysteray.com>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Andrew Dunstan" <andrew@dunslane.net>; "pgsql-hackers-win32"
<pgsql-hackers-win32@postgresql.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


Re: signals on windows

От
"Merlin Moncure"
Дата:
>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.

That is correct.  Signals in the Unix sense of the word do not exist in
win32.  A subset of them was emulated by the C runtime for compatibility
with dos applications.  All real win32 process messaging goes through
messages.

Exception handling, however, is a kernel primitive, and handles some
cases like int/0 that normally would be handled by signals.  Microsoft
hacked the C language to include exception support for this reason.

Merlin


Re: signals on windows

От
Andrew Dunstan
Дата:
Merlin Moncure wrote:

>>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.
>
>That is correct.  Signals in the Unix sense of the word do not exist in
>win32.  A subset of them was emulated by the C runtime for compatibility
>with dos applications.  All real win32 process messaging goes through
>messages.
>
>Exception handling, however, is a kernel primitive, and handles some
>cases like int/0 that normally would be handled by signals.  Microsoft
>hacked the C language to include exception support for this reason.
>
>
>
OK, so the practical question facing me is "am I doing the right thing
for signal handling on Windows in initdb.c, or is something else needed?"

cheers

andrew