From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25133 invoked by alias); 30 Apr 2010 17:55:23 -0000 Received: (qmail 25121 invoked by uid 22791); 30 Apr 2010 17:55:22 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Apr 2010 17:55:17 +0000 Received: (qmail 25415 invoked from network); 30 Apr 2010 17:55:15 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 30 Apr 2010 17:55:15 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] Fix gdbserver queued packet handling Date: Fri, 30 Apr 2010 17:55:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: Doug Evans References: <20100430171731.5600984398@ruffy.mtv.corp.google.com> In-Reply-To: <20100430171731.5600984398@ruffy.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201004301855.12464.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg01006.txt.bz2 On Friday 30 April 2010 18:17:31, Doug Evans wrote: > 2010-04-30 Doug Evans > > * server.h (queue_file_read_event): Declare. > (reschedule_remote): Declare. > * event-loop.c (queue_file_read_event): New function. > * remote-utils.c (reschedule_remote): New function. > (readchar_buf, readchar_bufcnt, readchar_bufp): New static globals, > moved out of readchar. > * server.c (handle_serial_event): Call reschedule_remote. This looks good, thanks. Please apply. > @@ -3009,6 +3009,10 @@ handle_serial_event (int err, gdb_client > Important in the non-stop mode asynchronous protocol. */ > set_desired_inferior (1); > > + /* Give the packet reader a chance to schedule more work before > + we go to sleep. */ > + reschedule_remote (); > + This seems to break the abstraction a bit. GDB attempts a reschedule on every `readchar', and avoids unnecessary calls into the event loop by maintaining a state machine, so everything is nicelly hidden within the serial handling code. But I'm fine with this simpler mechanism. I can't think of any reads from the socket outside of handle_serial_event; we'd be still in trouble this way if there were. In non-stop, we push stop notifications to gdb when handling target events, but asynchronous RSP notifications are a special kind of packet that is never acked, even if no-ack is off, so not even those cause reads that could cause data being pulled to the buffer. -- Pedro Alves