Comment 46 for bug 73536

(In reply to Karl Tomlinson (:karlt, offline til July 2) from comment #29)
> Is there a reason you chose to use SA_RESTART? Not sure it makes much
> difference in practice, but I would have expected an interrupt signal to try
> to abort ASAP rather than restarting a system call.

I would expect that too, but since we're not actually quitting immediately, enabling automatic restart of anything still in-progress seems reasonable, giving those calls a chance to complete, etc. I'd be really surprised if all the code in Gecko &co. was prepared to handle interrupted system calls anyway.

> The app is meant to exit by reraising the signal. The glibc page says
> "should
> end by specifying the default action for the signal that happened and then
> reraising it", but I think it is actually more correct use the previous
> action
> to chain up to other signal handlers, which will eventually raise with the
> default action. If there is no appropriate place to raise the right signal,
> then this may be more trouble than it is worth. If we don't do this, then
> that is another good reason not to handle SIGQUIT.

I assume you mean re-raising once we've handled application shutdown? Oof, that's quite some complexity. I appreciate the philosophical point behind trying to exit with the proper codes, but I'm not sure it makes much pragmatic difference here. And for things like nsProfileLock, it seems like a proper invocation of the shutdown process, as triggered by this patch, makes much more sense than trying to invoke nsProfileLock's signal handlers.