Roland McGrath <[EMAIL PROTECTED]> writes: > One has always seen this from time to time on any system, and I do see it > once in a while on Linux. I believe this happens when a second SIGINT is > received while quit-flag is still set. That may just mean that the whole > path of the first signal getting handled, the quit getting up to Lisp and > being handled, is a bit slower so that it's done all done by the time you > do a second C-c and a second SIGINT interrupts that path. Or it could mean > something else like the original signal is delayed in reaching Emacs for > some reason so that it appears to have taken a long time to process.
Here's a guess. Suppose two rapid C-g's come in before Emacs has a chance to respond, because, say, it's paged out. In the Hurd, two separate sig-post RPC's get queued. The first one pushes to the signal handler, and sets the quit flag, and the handler returns. Meanwhile the second RPC was received by the signal thread, and marked the signal pending (because the handler has it blocked). The handler returns, and the second signal is immediately taken. Emacs hasn't had a chance to notice the quit flag, and suspends. By contrast, the same thing happens in Linux only if the second C-g happens *while the signal handler is running*, which is very hard timing to achieve. If the process hasn't woken up at all, then the second C-g is just a duplicate signal. Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
