Re: More info on sporadic OS/X crash

[Steven Tamm <steventamm@mac.com>]

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 
>>>>>> <steventamm@mac.com> 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
> 				mituharu@math.s.chiba-u.ac.jp