Comment on attachment 618671 patch Communicating via pipe is the only reasonable async-signal-safe way that I know to signal the event loop. eForceQuit on SIGINT sounds sensible to me. I wouldn't implement this for SIGQUIT for the reasons you list in comment 26.
It should be possible to share the single existing pipe by sending the appropriate tokens down the same mPipeFDs. 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. These signal handlers should by removed once one is called. Once they've sent the eForceQuit, sending that again will not achieve much. When they remove themselves, they should restore the previous signal handler. See how this is done in nsProfileLock.cpp, and nsProfileLock is really the reason why the previous handler needs to be restored. I assume embedders have their own event loop and so this code won't be used. That is good as this could interfere with their signal handlers. 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. -- 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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
