From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: C-g crash redux Date: Fri, 04 Aug 2006 11:26:18 -0400 Message-ID: <877j1owmhx.fsf@stupidchicken.com> References: <877j1qvp4k.fsf@pacem.orebokech.com> <17617.8764.824445.882539@kahikatea.snap.net.nz> <87fygd97j0.fsf@stupidchicken.com> <87zmelfihg.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1154705187 25478 80.91.229.2 (4 Aug 2006 15:26:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 4 Aug 2006 15:26:27 +0000 (UTC) Cc: Nick Roberts , Romain Francoise , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 04 17:26:15 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G91YI-0000CZ-4b for ged-emacs-devel@m.gmane.org; Fri, 04 Aug 2006 17:25:30 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G91YH-0002GZ-L9 for ged-emacs-devel@m.gmane.org; Fri, 04 Aug 2006 11:25:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G91Y7-0002G7-4k for emacs-devel@gnu.org; Fri, 04 Aug 2006 11:25:19 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G91Y5-0002FL-G9 for emacs-devel@gnu.org; Fri, 04 Aug 2006 11:25:18 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G91Y5-0002FI-Cx for emacs-devel@gnu.org; Fri, 04 Aug 2006 11:25:17 -0400 Original-Received: from [18.19.1.138] (helo=cyd) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G91bf-0005rY-Ta for emacs-devel@gnu.org; Fri, 04 Aug 2006 11:28:59 -0400 Original-Received: by cyd (Postfix, from userid 1000) id 7701A4E2CC; Fri, 4 Aug 2006 11:26:18 -0400 (EDT) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Fri, 04 Aug 2006 13:12:29 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58096 Archived-At: storm@cua.dk (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 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?