From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23651 invoked by alias); 13 Mar 2005 19:41:21 -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 23589 invoked from network); 13 Mar 2005 19:41:10 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 13 Mar 2005 19:41:10 -0000 Received: from zaretski (IGLD-84-228-249-95.inter.net.il [84.228.249.95]) by legolas.inter.net.il (MOS 3.5.6-GR) with ESMTP id DXU56505 (AUTH halo1); Sun, 13 Mar 2005 21:40:15 +0200 (IST) Date: Sun, 13 Mar 2005 19:41:00 -0000 From: "Eli Zaretskii" To: Nick Roberts Message-ID: <01c52804$Blat.v2.4$4a0be180@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: drow@false.org, dave.korn@artimi.com, kostik@ispras.ru, gdb@sources.redhat.com In-reply-to: <16948.2374.864364.458035@farnswood.snap.net.nz> (message from Nick Roberts on Sun, 13 Mar 2005 22:35:02 +1300) Subject: Re: MI output command error Reply-to: Eli Zaretskii References: <16946.1979.617105.196894@farnswood.snap.net.nz> <20050311213042.GA14428@nevyn.them.org> <16946.4725.343793.980977@farnswood.snap.net.nz> <01c526ed$Blat.v2.4$2b933720@zahav.net.il> <16948.2374.864364.458035@farnswood.snap.net.nz> X-SW-Source: 2005-03/txt/msg00147.txt.bz2 > From: Nick Roberts > Date: Sun, 13 Mar 2005 22:35:02 +1300 > Cc: drow@false.org, dave.korn@artimi.com, kostik@ispras.ru, > gdb@sources.redhat.com > > > I'm all for documenting this in some useful way, but I fail to see how > > could this be done. Describing the async operation itself is already > > a big challenge, as the details are extremely confusing, unless you've > > read the code several times and have a good understanding of the > > underlying system calls (like `poll' and `select'). Differences > > between interpreters add another dimension of complexity to this. > > Well for someone to be able to code it must mean that it can be documented. > But if you mean that those who did the coding are no longer available to > do the documenting, then I can see this would be a difficult task. People who code are generally never available for documenting (present company excluded), that's why gdbint.texinfo is in such poor shape ;-) But what I meant was that, knowing what I do about the event loop, I don't know how to document it in a useful way, because talking about async operation is generally hard. Of course, I will applaud anyone who tries, and will try to help such an effort ion any way I can. > Actually if the asynchronous operation was working, I'm not sure what I would > do with it. When I debug, I'm used to waiting for execution to stop. Precisely. That is one reason why async CLI operation was never fully implemented: the event loop is ready for it, but the CLI layer simply waits until some event comes in.