[Bug 73536]

[Karlt]

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 Mozilla
Bugs, which is subscribed to firefox-3.0 in 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