[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More info on sporadic OS/X crash

From: Steven Tamm
Subject: Re: More info on sporadic OS/X crash
Date: Mon, 26 Apr 2004 09:27:52 -0700

The reason for all of the polling nonsense in the first place is to deal with runaway processes. For example, compile this program and run it using (shell-command) or M-!
#include <stdio.h>
int main(int argc, char** argv) {
  while (1)
If C-g interrupts it, then it still works. With carbon emacs as it is now, this works.

The other example would be to setup an infinite loop *inside* emacs; i.e. not as a subprocesses. The simplest being:
(while t t)
Right now, with Carbon Emacs, this causes the beachball of death and C-g does nothing. This is why the "mac_check_for_quit_char" is peppered throughout the code; but in this instance it doesn't work. Of course if you send a SIGINT to the process it works... And (while t (eval t)), a more realistic example, C-g does work.

I filed a bug with Apple a year and a half ago asking if an application could setup a key that causes a signal, but I can't seem to find the resolution for it.


On Apr 26, 2004, at 6:15 AM, YAMAMOTO Mitsuharu wrote:

On Sun, 25 Apr 2004 10:49:07 -0700, Steven Tamm <address@hidden> said:

The patch seemed to make sense to be, except for the FD_CLR
(i.e. the bug in select from 10.1) I forgot to ask, have you tried
that patch on 10.2 or just 10.3?

I just tried the patch on both 10.1.5 and 10.2.8, but I could not find
any problems by a few tests on subprocesses.  If you have a specific
example, maybe I can test it.

And with the non-carbon build?

For the X11 build, fd 0 is excluded from input_wait_mask with
add_keyboard_wait_descriptor in x_term_init.  For the Carbon build, fd
0 is never consulted in sys_select (in mac.c with the patch), but the
window event queue is consulted instead.

A comment in mac.c says:

   When Emacs is started from the Finder, SELECT always immediately
   returns as if input is present when file descriptor 0 is polled for
   input.  Strangely, when Emacs is run as a GUI application from the
   command line, it blocks in the same situation.  This `wrapper' of
   the system call SELECT corrects this discrepancy.

According to the output of lsof, fd 0 is bound to /dev/null for the
former case, whereas it is bound to the tty from which Emacs is
invoked for the latter case.  That would explain the above phenomena.

                                     YAMAMOTO Mitsuharu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]