From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22251 invoked by alias); 13 Oct 2006 13:49:00 -0000 Received: (qmail 22243 invoked by uid 22791); 13 Oct 2006 13:49:00 -0000 X-Spam-Check-By: sourceware.org Received: from w099.z064220152.sjc-ca.dsl.cnc.net (HELO bluesmobile.corp.specifix.com) (64.220.152.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Oct 2006 13:48:54 +0000 Received: from [::1] (bluesmobile.corp.specifix.com [192.168.1.32]) by bluesmobile.corp.specifix.com (Postfix) with ESMTP id EA4863B833; Fri, 13 Oct 2006 06:43:22 -0700 (PDT) From: Fred Fish Reply-To: fnf@specifix.com To: Daniel Jacobowitz Subject: Re: [RFC] Patch for QUIT macro support Date: Fri, 13 Oct 2006 13:49:00 -0000 User-Agent: KMail/1.9.3 Cc: GDB Patches References: <200610130543.25806.fnf@specifix.com> <200610130622.39164.fnf@specifix.com> <20061013133046.GA9478@nevyn.them.org> In-Reply-To: <20061013133046.GA9478@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610130648.31875.fnf@specifix.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00151.txt.bz2 On Friday 13 October 2006 06:30, Daniel Jacobowitz wrote: > Do you mean the big async patch? If so it's still worth fixing this in > isolation. Yes, just search for the couple of hunks that make changes to "quit_flag". The key difference between my patch and Nick's is the test in async_request_quit to avoid call quit twice (once from the QUIT macro and once when the event loop gets around to checking the signal handlers). Here's the patch I'm now testing. -Fred Index: gdb/event-top.c =================================================================== RCS file: /cvs/src/src/gdb/event-top.c,v retrieving revision 1.46 diff -c -r1.46 event-top.c *** gdb/event-top.c 21 Jul 2006 14:46:53 -0000 1.46 --- gdb/event-top.c 13 Oct 2006 07:49:52 -0000 *************** *** 958,963 **** --- 1002,1017 ---- { signal (sig, handle_sigint); + /* We used to set the quit flag in async_request_quit, which is either + called when immediate_quit is 1, or when we get back to the event + loop. This is wrong, because you could be running in a loop reading + in symfiles or something, and it could be quite a while before you + get to the event loop. Instead, set quit_flag to 1 here, then mark + the sigint handler as ready. Then if somebody calls QUIT before you + get to the event loop, they will unwind as expected. */ + + quit_flag = 1; + /* If immediate_quit is set, we go ahead and process the SIGINT right away, even if we usually would defer this to the event loop. The assumption here is that it is safe to process ^C immediately if *************** *** 986,992 **** void async_request_quit (gdb_client_data arg) { ! quit_flag = 1; quit (); } --- 1040,1053 ---- void async_request_quit (gdb_client_data arg) { ! /* If the quit_flag has gotten reset back to 0 by the time we get ! back here, that means that an exception was thrown to unwind ! the current command before we got back to the event loop. So ! there is no reason to call quit again here. */ ! ! if (quit_flag == 0) ! return; ! quit (); }