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
