From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32588 invoked by alias); 30 May 2006 21:11:27 -0000 Received: (qmail 32577 invoked by uid 22791); 30 May 2006 21:11:26 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 30 May 2006 21:11:24 +0000 Received: from relay8.apple.com (relay8.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k4ULAlGP016640; Tue, 30 May 2006 14:10:47 -0700 (PDT) Received: from [17.201.22.244] (unknown [17.201.22.244]) by relay8.apple.com (Apple SCV relay) with ESMTP id 9A0DE4AD; Tue, 30 May 2006 14:10:47 -0700 (PDT) In-Reply-To: <20060530204553.GA23684@nevyn.them.org> References: <20060530171518.GB31100@brasko.net> <7A4B9D88-47FB-4721-949F-632AF2E449FC@apple.com> <20060530175310.GD31100@brasko.net> <20060530181143.GE31100@brasko.net> <6FE49E5C-CD1C-45FC-B2FF-97E4B2FFA779@apple.com> <20060530185446.GF31100@brasko.net> <6CF6F2BF-276F-4634-BA75-80698EEE64EE@apple.com> <20060530204553.GA23684@nevyn.them.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D653D4A-A9FE-4B53-A6CB-3464235216CF@apple.com> Cc: Bob Rossi , gdb@sources.redhat.com Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI query questions Date: Tue, 30 May 2006 21:30:00 -0000 To: Daniel Jacobowitz X-Mailer: Apple Mail (2.749.3) 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: 2006-05/txt/msg00406.txt.bz2 On May 30, 2006, at 1:45 PM, Daniel Jacobowitz wrote: > On Tue, May 30, 2006 at 01:14:12PM -0700, Jim Ingham wrote: >> I also like this =read-one-line thingie, because it makes it explicit >> what's going on, namely something other than the MI is trying to read >> one line of input. So the FE should solicit a line of input from >> whoever it's getting that from in the command that caused this >> message to be delivered, and send it on... > > While I agree at first look, on the other hand: > > (A) It messes up pipelining. You can't throw five commands at GDB at > once, if one of them might eat further input. Yes, though another approach is to mark commands that can't safely be in the middle of a pipeline - of which there is really just one: - interpreter-exec. Then if you do pipeline those it's your own fault. After all, I can't think of any case where a real MI command has any business prompting for more info, and I don't think we would want to make that an available mode for MI commands. I think for the MI itself it's much better to have them do their job atomically... So the issue only arises when you are passing control to another interpreter, and waiting till that has given control back before issuing more commands seems the safe thing to do. > > (B) It makes parsing the output somewhat trickier. > > Would it be helpful to have some general solution for this, presumably > involving completions (i.e. closures)? Come back and answer the > prompt > when you're ready? This would probably be nicer, though I'm not sure it's worth the effort unless there are other places where we can forsee using this beyond -interpreter-exec. Jim