[Top][All Lists]

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

Re: C-g crash redux

From: Kim F. Storm
Subject: Re: C-g crash redux
Date: Fri, 04 Aug 2006 00:29:34 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Chong Yidong <address@hidden> writes:

>>> Emacs can be made to crash simply by evaluating (sit-for 4) in the scratch
>>> buffer and typing C-g before four seconds elapse.
>>> It's due to this change:
>>> 2006-08-01  Kim F. Storm  <address@hidden>
>>>     * process.c (wait_reading_process_output_unwind): New function.
>>>     Restores waiting_for_user_input_p to saved value.
>>>     (wait_reading_process_output): Unwind protect waiting_for_user_input_p
>>>     instead of save/restore old value on stack.
>>> Presumably wait_reading_process_output is interrupted before it can do:
>>>   unbind_to (count, Qnil);
>> Huh?  Is that really possible?
>> What kind of interrupt can cause unwind_protect forms NOT to be run?
> Typing C-g, which runs interrupt_signal, runs quit_throw_to_read_char
> instead of Fsignal during when waiting_for_input is set (as it is
> during wait_reading_process_output).  If I understand correctly, the
> purpose is to enable read-char to return a `C-g' character; and that's
> why it's both undesirable and unnecesssary to use a
> record_unwind_protect inside wait_reading_process_output.

Ok, I see.

> I'll go ahead and revert the 2006-08-01 change.


But how do we ensure that waiting_for_user_input_p is restored
correctly on C-g?

Or isn't that necessary?

Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

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