emacs-devel
[Top][All Lists]
Advanced

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

Re: C-g crash redux


From: Chong Yidong
Subject: Re: C-g crash redux
Date: Fri, 04 Aug 2006 11:26:18 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden (Kim F. Storm) writes:

>> That's not necessary, since quit_throw_to_read_char calls
>> clear_waiting_for_input, which resets waiting_for_input to 0.
>
> But it doesn't restore waiting_for_user_input_p to its
> previous/original value.
>
> Pls. see the comment about waiting_for_user_input_p in process.c.

Ah, sorry.  I got confused between waiting_for_user_input_p and
waiting_for_input.


Nick Roberts <address@hidden> writes:

> I think that Fsignal should get called (perhaps with QUIT) before
> Emacs gets back to the command loop (or at least before further
> expressions/bytecode is evaluated) so that unbind_to gets called and
> the binding stack stays balanced.

I am hesitant to do this.  The code in question looks delicate.

Another approach, which may be less risky, is to protect the portions
of code in read_char where getcjmp is active.  We should then be able
to safely use unwind protects inside wait_reading_process_output.
Something like this:

      save_getcjmp (save_jump);
      restore_getcjmp (local_getcjmp);
      timer_start_idle ();
      c = kbd_buffer_get_event (&kb, used_mouse_menu, end_time);
      restore_getcjmp (save_jump);

 -->

      count = SPECPDL_INDEX ();
      save_getcjmp (save_jump);
      restore_getcjmp (local_getcjmp);
      timer_start_idle ();
      c = kbd_buffer_get_event (&kb, used_mouse_menu, end_time);
      restore_getcjmp (save_jump);
      unbind_to (count);

What do you think?




reply via email to

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