*BSD News Article 5124


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).