Comment 56 for bug 73536

Comment on attachment 8626516
bug336193.patch

Unfortunately, the last paragraph of comment 23 is still relevant.

(In reply to Kestrel from comment #39)
> * nsAppStartup::Quit calls nsIAppShell::Exit asynchronously which does most
> of the work so it doesn't block the signal handler.

It is more complicated than just not blocking the signal handler.
See man 7 signal:
  "Async-signal-safe functions
       A signal handler function must be very careful, since processing
       elsewhere may be interrupted at some arbitrary point in the execution
       of the program. POSIX has the concept of "safe function". If a
       signal interrupts the execution of an unsafe function, and handler
       calls an unsafe function, then the behavior of the program is
       undefined."

One of the most likely problems is taking a lock, if the process is interrupted with the lock already held. For example, nsComponentManagerImpl::GetService() uses locks, and memory allocations are also likely to use locks.

Also, unless the signal mask of every thread is carefully managed, the signals may be received on any thread. Therefore any methods called that have state would need to be thread-safe, but locks can't be used for the reason described above.

"A process-directed signal may be delivered to any one of the threads that
 does not currently have the signal blocked. If more than one of the threads
 has the signal unblocked, then the kernel chooses an arbitrary thread to
 which to deliver the signal."