From: James Y K. <fo...@fu...> - 2009-12-29 07:09:03
|
On Dec 29, 2009, at 12:08 AM, Gábor Melis wrote: > The current code handles all cases properly and as a bonus by having > to > explicitly null out the low level handler you are forced to > acknowledge > that what you are doing is dangerous: > - handling of async SIGABRTs will be unsafe > - the image will die if the handler returns I still don't get the "unsafe" aspect. It seems to me from your description that the worst thing that might happen would be for the process to actually abort. And that's only if an async SIGABRT and a abort() call are happening at the same time? > If a thread calls abort() SIGABRT gets unblocked and delivered to the > calling thread. The handler will want to have it blocked to protect > against async SIGABRTs until it is ready to call into lisp which could > be accomplished just by adding it to deferrables in which case > (without- > interrupts (call-llvm)) will die when the signal is deferred and the > handler apparently returns. Oops. It doesn't have to return in that situation, it could lose() instead. Either way, it's no worse than the current situation, where it *always* dies. Hardly any code runs inside (without-interrupts), so if the only choice is to die in that case, I don't really mind... Just in case it's wasn't clear, I don't really care about being able to install my own signal handler. What I'd like to see is SIGABRT invoking the lisp-side debugger, like it did before, in as many situations as possible. I mean it seems just a bit crazy that a SIGSEGV is recoverable, in the usual case, but a SIGABRT from a failed assert is not! ...But speaking of SEGV: Why doesn't it have exactly the same concerns? You can't block/defer handling of a synchronous SEGV, and someone can send an async SEGV at any time. James |