On Wed, Feb 27, 2008 at 02:38:55PM -0800, David Powell wrote: > James Carlson wrote: > > David Powell writes: > >> Generating an event on abort(3c) makes a lot of sense. > >> > >> WRT naked SIGABRTs, the default disposition for SIGABRT is to dump a > >> core, and core dump events already include the signal number that > >> caused them. A separate event in this case doesn't buy us much. > > > > That means an application that implements its own abort-like function > > by kill(0,SIGABRT) and that hooks SIGABRT to do something silly (like > > generating a traceback in a debug log) won't treat the ensuing exit as > > a failure. > > Ah, generate a signal on any delivery of SIGABRT. > > > I guess that's just a limitation ... > > I wouldn't call that a limitation, but an ambiguity. A process could > also hook into SIGABRT and continue running. > > This is almost identical to the generic signal case listed in the bug > report -- we have a failure that isn't externally observable or the > semantics of an externally observable event are unknown -- and I > would similarly recommend that the application itself explicitly > generate an event when it determines that a failure has occurred. > > Dave
The contract behavior can also trivially be implemented to only deliver the notification if the signal's disposition is SIG_DFL. i.e. assume anyone with a SIGABRT handler is doing their own thing. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
