[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Windows signal handler and Control-C

From: Tobias Ringstrom <tobias_at_ringstrom.mine.nu>
Date: 2004-01-19 18:36:53 CET

Greg Hudson wrote:

>On Fri, 2004-01-16 at 14:32, Garrett Rooney wrote:
>>I was using signal in my experiments, so yes, it's quite likely that
>>this could be fixed in APR by using sigaction or something. If that's
>>the case, fine.
>apr_signal() already uses sigaction under Unix, if it finds it during
>configure. I can't tell what the win32 implementation of apr_signal()
>is; it might just be the Unix implementation, in which case the lack of
>APR_HAVE_SIGACTION might lead it to erroneously use signal().
The problem is that apr_signal does not document whether it resets the
signal handler or not, and that it relly does behave differently on
different platforms. It obviously does reset it on Win32 which uses
signal (since it does not have sigaction). The signal() function is
known to behave differently on BSD and non-BSD unixes. Since sigaction()
is supposed to be async signal safe (at least according to SuSv2), it
should be safe to call apr_signal from the signal handler, at least
until apr starts to behave consistently on all platforms. Adding a
apr_signal(SIGINT, SIG_IGN) to the SIGINT handler should work, but needs

[While investigating, I found the following interesting note on

"*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 don't know what they mean by the first paragraph, but perhaps they
mean non-console Win32 applications. The last sentence it particularly
funny, though.]


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 19 18:37:29 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.