(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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/73536 Title: MASTER Firefox crashes on instant X server shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/73536/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
