From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26206 invoked by alias); 6 Sep 2005 15:42:57 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26165 invoked by uid 22791); 6 Sep 2005 15:42:51 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 06 Sep 2005 15:42:51 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1ECfaz-0000sb-MQ; Tue, 06 Sep 2005 11:42:49 -0400 Date: Tue, 06 Sep 2005 15:42:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: The 'x' command: size problem Message-ID: <20050906154249.GA3270@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <20050906152448.GA2444@nevyn.them.org> <200509061935.12549.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509061935.12549.ghost@cs.msu.su> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00034.txt.bz2 On Tue, Sep 06, 2005 at 07:35:12PM +0400, Vladimir Prus wrote: > No, it's not very hard. But given anynchronious nature of communication with > gdb I'm trying to limit the number of queries to minimum, to minimize the > amount of data I have to keep. The MI data stream is basically synchronous. Sure, there are asynchronous notifications in it. But a synchronous reply always corresponds to the previously implemented synchronous command, doesn't it? It's serialized, so if you have a lot of different threads wanting to bang away at GDB, sure you're going to need some bookkeeping. > And it'll give you a whole new host of issues keeping up with the changing interface. And GDB does some fairly complicated things using signals and wait, which can yield very surprising behavior if you're running it in the same context as your GUI. I don't see how it would eliminate the need for asynchronous interfaces, either. I still think the MI communication model we've evolved is the best choice. -- Daniel Jacobowitz CodeSourcery, LLC