From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8830 invoked by alias); 20 Feb 2004 16:14:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8819 invoked from network); 20 Feb 2004 16:14:03 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 20 Feb 2004 16:14:03 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9D8EC2B92; Fri, 20 Feb 2004 11:14:01 -0500 (EST) Message-ID: <40363249.4090607@gnu.org> Date: Fri, 20 Feb 2004 16:14:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Elena Zannoni , Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/RFC] QUIT doesn't seem to be working !? References: <20030812222211.GC923@gnat.com> <16435.52781.747628.886278@localhost.redhat.com> In-Reply-To: <16435.52781.747628.886278@localhost.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00555.txt.bz2 Some related history: non-blocking reads/writes and event loops http://sources.redhat.com/ml/gdb/2000-06/msg00088.html remote.c's "async", "extended-async" back ends http://sources.redhat.com/ml/gdb/2001-02/msg00016.html remote.c and a re-entrant event-loop http://sources.redhat.com/ml/gdb/2000-06/msg00144.html > I think your observations are correct. quit_flag is not set when we > hit the QUITs, if we use the event loop. I remember testing the > behavior of ^-C several times, when I wrote that stuff, but I focused > more on interrupting a running target (launched with run&, etc) for > the async remote case. There is even a mechanism in gdb to handle a > ^-C hit twice. > > Unfortunately I think that your patch is not completely correct. You > set up *both* the QUIT machinery and the event-loop to process *one* > SIGINT the next time through. Whatever one you reach first, it will > leave a non-existant event set for the other. > > Probably for the event-loop case we should forget quit_flag and just > rely on the markers being set in the event-loop machinery. Which means > that QUIT (or equivalent) will have to figure out if there are any > high priority events to be processed. Which, if you think about it, is > like saying that there will be a 'lower-level/inner-level/secondary' > event loop. In this sigint case, for QUIT to be able to pull out the > interrupt related markers from the event loop, it means that those > markers now need to identify themselves somehow. The event loop is > currently completely agnostic about the kind of events to be > processed. It only knows that they are generated by a signal (any > signal), while we want to pull out only the sigint ones. Based on the above links. So this means that QUIT: #define QUIT { \ if (quit_flag) quit (); \ if (interactive_hook) interactive_hook (); \ } should be replaced by something like: #define QUIT keep_event_loop_alive (); > Actually the event loop knows only about 2 kinds (well, 3) kinds of > events: signals and file-descriptors related events (and timers). We > are talking here about subverting that categorization by introducing a > urgent/high priority kind of event that needs to be processed > right now, w/o waiting until you get back to the event loop proper. > > So, since 6.1 is approaching, I would mark this as a known problem, > and try to solve it in mainline, after the branch is cut. Yes. I did a quick user poll over lunch and everyone indicated that contrl-c "works for me" (the sample included heavy java and C++ users!). Andrew