Thread: 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@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
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@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
>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
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