Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!uunet!mcsun!sun4nl!eur.nl!pk From: pk@cs.few.eur.nl (Paul Kranenburg) Subject: Re: Program dies with FP Exception Message-ID: <1992Sep16.102617.24631@cs.few.eur.nl> Sender: news@cs.few.eur.nl Reply-To: pk@cs.eur.nl Organization: Erasmus University Rotterdam References: <STARK.92Sep13002650@sbstark.cs.sunysb.edu> <1992Sep13.083846.6134@fcom.cc.utah.edu> <1992Sep14.151555.12300@cs.few.eur.nl> <BuMMFx.Isq@Novell.COM> Date: Wed, 16 Sep 1992 10:26:17 GMT Lines: 21 In <BuMMFx.Isq@Novell.COM> terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert) writes: [...] >>.. or you get your signal immediately, provided you have a handler set, or >>you get it on return from the interrupt (trap), provided the AST (Async. >>System Trap) stuff is implemented which is then invoked from `signotify()'. >This is, of course, correct. However, very few programs that trap SIGFPE >will fail as a reult of getting one. Instead, the handler will be called, >and the program will continue executing. The other two delivery mechanisms >depend on having a handler registered. >So register a handler and dump core in the handler to make it act "correctly" >-- or fix the exception and make it act as expected. Hmm, the point I was trying to make was that `aston()' and therefore `signotify()' are effectively no-ops in the current 0.1 release. It is for this reason that (asynchronously generated) signals are not delivered until the next time the process runs in kernel mode (by doing a system call or getting scheduled).