OS X: C-g does not break out of infinite loop

OS X: C-g does not break out of infinite loop

[John Owens]

When sending a large email via FLIM, I could not break
out of the send using C-g. I thought this was a FLIM
problem, but Yoichi Nakayama ably identified it as a
emacs problem (on OS X specifically). The problem is
described in more detail here:

http://article.gmane.org/gmane.mail.wanderlust.general/632

with Yoichi's response (together with a test case that
I can reproduce: C-g on OS X cannot recover from
evaling any of the following three:

1. (condition-case nil (while 1) (error (error "catch
error")) (quit (error "catch quit")))
2. (condition-case nil (while 1) (error (error "catch
error")))
3. (while 1)

) at:

http://article.gmane.org/gmane.mail.wanderlust.general/635

(He verified this with GNU Emacs 21.3.50.1
(powerpc-apple-darwin7.3.0) of 2004-05-08; I also
verified it with GNU Emacs 21.3.50.1
(powerpc-apple-darwin7.4.0) of 2004-07-07.)

He also points out that C-g has had historical
problems in OS X:

http://article.gmane.org/gmane.emacs.macintosh.devel/46

Given that the above message indicates that the 10.2
OS X release allowed support for handling C-g
properly, maybe now's a good time to do so?

JDO


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Re: OS X: C-g does not break out of infinite loop

[Richard Stallman]

    with Yoichi's response (together with a test case that
    I can reproduce: C-g on OS X cannot recover from
    evaling any of the following three:

    1. (condition-case nil (while 1) (error (error "catch
    error")) (quit (error "catch quit")))
    2. (condition-case nil (while 1) (error (error "catch
    error")))
    3. (while 1)

It sounds like the mechanism for detecting C-g may need a redesign.
Is there any Lisp program you can successfully interrupt with C-g?

Re: OS X: C-g does not break out of infinite loop

[YAMAMOTO Mitsuharu]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

>>>>> On Thu, 15 Jul 2004 09:17:36 -0400, Richard Stallman <rms@gnu.org> said:

>> with Yoichi's response (together with a test case that I can
>> reproduce: C-g on OS X cannot recover from evaling any of the
>> following three:

>> 1. (condition-case nil (while 1) (error (error "catch error"))
>> (quit (error "catch quit")))
>> 2. (condition-case nil (while 1) (error (error "catch error")))
>> 3. (while 1)

> It sounds like the mechanism for detecting C-g may need a redesign.
> Is there any Lisp program you can successfully interrupt with C-g?

That problem was mentioned three months ago, but maybe obscured by
other urgent problems.

http://lists.gnu.org/archive/html/emacs-devel/2004-04/msg00783.html
http://lists.gnu.org/archive/html/emacs-devel/2004-04/msg01072.html

The attached is a patch for the latest CVS.  With this patch, all the
above examples can be quit by C-g on OS X (Carbon).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

[-- Attachment #2: diff-event.gz --]
[-- Type: application/octet-stream, Size: 2888 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: OS X: C-g does not break out of infinite loop

[John Owens]

--- YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
wrote:
> The attached is a patch for the latest CVS.  With
> this patch, all the
> above examples can be quit by C-g on OS X (Carbon).

I confirm that with the latest CVS, Mitsuharu's patch
both fixes all three test cases from Yoichi and also
allows me to C-g out of a send. Fantastic! Thanks for
the quick patch.

JDO



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Re: OS X: C-g does not break out of infinite loop

[Steven Tamm]

On Jul 18, 2004, at 11:00 PM, YAMAMOTO Mitsuharu wrote:

> Hi,
> I thought I've explained that in the following message:
>
> http://lists.gnu.org/archive/html/emacs-devel/2004-04/msg01015.html
>
> Maybe your concern is another issue?  Anyway, I can test with Mac OS X
> 10.1.5 if you give me an example that may cause some problems.

I missed that explanation during my prolonged illness.  It makes sense, 
given the rewrite of sys_select (Due to the "why didn't i think of 
that" part of using ReceiveNextEvent with the timeout instead of 
unnecessary selects).

So I guess the only thing I need to keep reverifying after each OS 
release is the vfork problem.

>> However, I will check it in and let the 10.1 people complain because
>> the polling appears to work .
> Seems like the old patch is applied.  It may cause a hang because of
> lack of BLOCK_INPUT/UNBLOCK_INPUT for ReceiveNextEvent, which I
> mentioned in
> http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg00016.html
> Could you apply the attached patch over the current CVS?

Done.  I have noticed that responding to blocked subcommands still 
takes a second to respond, which seems odd since it should be 200ms.  
Have you noticed this as well?

-Steven

Re: OS X: C-g does not break out of infinite loop

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 18 Jul 2004 23:38:19 -0700, Steven Tamm <steventamm@mac.com> said:

> I have noticed that responding to blocked subcommands still takes a
> second to respond, which seems odd since it should be 200ms.  Have
> you noticed this as well?

That is what I intended, and normal for the systems where SIGIO can't
be used for notification of input events.  The documentation of
`polling-period' says:

  *Interval between polling for input during Lisp execution.
  The reason for polling is to make C-g work to stop a running program.
  Polling is needed only when using X windows and SIGIO does not work.
  Polling is automatically disabled in all other cases.

During Lisp or synchronous subprocess execution, window events
(including keyboard ones) are inspected every `polling-period' (2 by
default) seconds.  The timeout `200ms' (I think you meant 20ms =
20000ns in mac.c) is just for multiplexing the inspection of window
events by ReceiveNextEvent and that of process I/O by select.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp