www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/01/15/23:21:30

Date: Thu, 15 Jan 1998 20:20:42 -0800 (PST)
Message-Id: <199801160420.UAA09731@adit.ap.net>
Mime-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From: Nate Eldredge <eldredge AT ap DOT net>
Subject: Re: Writing a SIGINT handler.
Cc: Paul Derbyshire <ao950 AT FreeNet DOT Carleton DOT CA>, djgpp AT delorie DOT com

At 01:17  1/15/1998 +0200, Eli Zaretskii wrote:
>
>On Wed, 14 Jan 1998, Nate Eldredge wrote:
>
>> >No.  SIGINT is not a true exception, it is faked by the DJGPP keyboard 
>> >handler when it sees either Ctrl-C or Ctrl-BREAK.  By the time your 
>> >handler is called, you are in a safe state, so you can do anything and 
>> >don't need to lock.
>> This is true of all signals, right?  Including hardware-generated ones like
>> SIGSEGV?
>
>Mostly, yes.  However, when SIGSEGV comes not from your program that
>just happened to dereference a null pointer, but from a real page
>fault in the DPMI host which somehow got unhandled by its VM manager,
>I would not risk another page fault that will be generated by your
>handler being paged out at that time.  DOS is certainly non-reentrant,
>and I don't generally trust even MS-Windows to handle such nested
>faults gracefully.
>
>Of course, usually you shouldn't have a reason to install a handler
>that is meant to catch real exceptions which don't originate from
>something your program did.
Sorry, I'm confused by the implications of this. What might cause such an
event, and how would my program be able to tell which was the actual cause?
It seems to me that such events could only be caused by a buggy DPMI host,
which isn't my fault anyway. I sincerely hope you aren't saying that signal
handlers are not safe.

Nate Eldredge
eldredge AT ap DOT net



- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019