signals on windows

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: pgsql-hackers-win32 <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: signals on windows
Date: 2003-10-06 16:01:38
Message-ID: 3F8191E2.7060801@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32


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

Responses

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Andrew Dunstan 2003-10-06 17:35:52 db encoding
Previous Message Andrew Dunstan 2003-10-04 23:15:15 Re: [HACKERS] initdb