Comment 41 for bug 73536

Revision history for this message
In , Nfroyd (nfroyd) wrote :

(In reply to Benjamin Smedberg [:bsmedberg] from comment #15)
> ok, fix it! I'd happily review a patch!

(In reply to Benjamin Smedberg [:bsmedberg] from comment #25)
> I am not the right person to review this, having never written anything
> useful with signal handlers.

I am confused. :)

> If I understand this correctly, the signal
> handler itself is signaling a pipe which wakes up the event loop. Is this
> because it is not safe to make any GTK calls from within the signal handler?

Doing almost anything non-trivial from a signal handler is a Bad Idea, unless you write your code very very carefully. I do not think GTK code follows the necessary rules for being callable from a signal handler.

> I do think that eForceQuit is correct for SIGTERM, but I wonder if we
> shouldn't be using eAttemptQuit for SIGQUIT, so that it can properly prompt
> for unsaved work.

Wikipedia suggests that SIGQUIT is sent "when the user requests that the process perform a core dump." The glibc info pages agree, but also suggest that "certain kinds of cleanups are best omitted in handling SIGQUIT." (e.g. you might want to examine temporary files along with the core dump you just received.) Given this information, I think eForceQuit is acceptable for both signals...and I doubt people SIGQUIT'ing applications is all that common anyway.