emacs-devel
[Top][All Lists]
Advanced

[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.

-Steven

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
                                address@hidden





reply via email to

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