From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8710 invoked by alias); 19 Nov 2005 09:04:22 -0000 Received: (qmail 8693 invoked by uid 22791); 19 Nov 2005 09:04:18 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 19 Nov 2005 09:04:18 +0000 Received: from kahikatea.snap.net.nz (p36-tnt1.snap.net.nz [202.124.110.36]) by viper.snap.net.nz (Postfix) with ESMTP id CE23772F7E2; Sat, 19 Nov 2005 22:04:09 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 93A0983F9; Sat, 19 Nov 2005 22:04:18 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17278.60050.74886.783071@kahikatea.snap.net.nz> Date: Sat, 19 Nov 2005 09:04:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI: is target running In-Reply-To: <200511181740.48427.ghost@cs.msu.su> References: <17277.55557.315710.118933@kahikatea.snap.net.nz> <200511181740.48427.ghost@cs.msu.su> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-11/txt/msg00420.txt.bz2 > > Yes, I think it should. I have made changes to GDB, based on Apple's work, > > that makes GDB run asynchronously. This means that the state of the > > inferior is reported regardless of whether the command executed was from MI > > or CLI. > > Cool. But what does "asynchronously" means, exactly? I'm not the expert, but I can tell you what I understand by it. Basically GDB can accept further input even while the inferior is running. I guess that the output of some commands will depend on the timing, but others won't - I'm not sure of the full implications. In terms of the code, target_can_async_p () is true and with MI, for example, GDB picks up mi_exec_async_cli_cmd_continuation to print the *stopped record, even with CLI commands like "run". But its probably better to let the code speak for itself when the branch is created. By giving each MI command a token number, it can be paired up with its output. There's no need to have the concept of a queue, and so I think the front-end is less likely to get confused. As far as I know, asynchronous operation fits in with the general aims of the GDB community, but it is certainly not something that I can implement on my own. So I can't say for sure that it will happen, but just that I would like it to happen. Nick