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: YAMAMOTO Mitsuharu
Subject: Re: More info on sporadic OS/X crash
Date: Tue, 27 Apr 2004 18:52:15 +0900
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Mon, 26 Apr 2004 09:27:52 -0700, Steven Tamm <address@hidden> said:

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

All the examples you mentioned above can be interrupted with the
patched version (also on 10.1).  That's not surprising because I just
imitated the way of event handling in Solaris (a system without SIGIO)
where the event queue is periodically (every 2 seconds by default)
polled using the alarm timer.  Not only C-g but also window events
such as window movement are processed at this timing, so one can move
the window during a command loop or waiting for a synchronous process,
although it is sluggish.

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

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