From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23632 invoked by alias); 26 Jan 2004 06:18:49 -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 23625 invoked from network); 26 Jan 2004 06:18:48 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 26 Jan 2004 06:18:48 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.24) id 1Al04A-0005G5-46; Mon, 26 Jan 2004 01:17:46 -0500 Date: Mon, 26 Jan 2004 06:18:00 -0000 Message-Id: From: Eli Zaretskii To: Mark Kettenis CC: gdb-patches@sources.redhat.com In-reply-to: <200401251732.i0PHWmRq007000@elgar.kettenis.dyndns.org> (message from Mark Kettenis on Sun, 25 Jan 2004 18:32:48 +0100 (CET)) Subject: Re: [PATCH] Partial infcmd.c cleanup Reply-to: Eli Zaretskii References: <200401251732.i0PHWmRq007000@elgar.kettenis.dyndns.org> X-SW-Source: 2004-01/txt/msg00665.txt.bz2 > Date: Sun, 25 Jan 2004 18:32:48 +0100 (CET) > From: Mark Kettenis > > Since I'll be changing this bit of code I though I'd give it a cleanup > first. Mostly wrapping long lines and adding some missing whitespace. > > Committed as obvious, I think changing finish_command_continuation from a void function into a static void function does not really qualify as obvious. I'm talking about this part of the patch: > /* Stuff that needs to be done by the finish command after the target > - has stopped. In asynchronous mode, we wait for the target to stop in > - the call to poll or select in the event loop, so it is impossible to > - do all the stuff as part of the finish_command function itself. The > - only chance we have to complete this command is in > - fetch_inferior_event, which is called by the event loop as soon as it > - detects that the target has stopped. This function is called via the > - cmd_continuation pointer. */ > -void > + has stopped. In asynchronous mode, we wait for the target to stop > + in the call to poll or select in the event loop, so it is > + impossible to do all the stuff as part of the finish_command > + function itself. The only chance we have to complete this command > + is in fetch_inferior_event, which is called by the event loop as > + soon as it detects that the target has stopped. This function is > + called via the cmd_continuation pointer. */ > + > +static void > finish_command_continuation (struct continuation_arg *arg) Not that I'm objected to this change, but IMHO it shouldn't have been done without at least a call for comments, or a few days of delay, to give people some time to react.