From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12543 invoked by alias); 1 May 2008 17:52:48 -0000 Received: (qmail 12529 invoked by uid 22791); 1 May 2008 17:52:47 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 May 2008 17:52:30 +0000 Received: (qmail 26570 invoked from network); 1 May 2008 17:52:28 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 May 2008 17:52:28 -0000 From: Pedro Alves To: Vladimir Prus Subject: Re: MI non-stop interface details Date: Thu, 01 May 2008 17:52:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb@sourceware.org, Pawel Piech , Marc Khouzam References: <200804261939.37635.vladimir@codesourcery.com> <200804301534.48779.pedro@codesourcery.com> <200805012121.51174.vladimir@codesourcery.com> In-Reply-To: <200805012121.51174.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805011852.25316.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00010.txt.bz2 Vladimir, A Thursday 01 May 2008 18:21:51, Vladimir Prus wrote: > [Pedro and I discussed this a bit on IRC, and...] > > On IRC, you said: > > [20:40] in CLI it's lame to have to know the thread id, and to > have to pass it to "continue". [20:43] break 20; ; > next; next; ; another next; one > step; continue; uuups, other thread resumed too... > > I think this is valid point -- if user, in CLI, enables non-stop, then > having "continue" just work, resuming one thread, seems right. Are you > going to add "--all" to "continue"? Sure! I hereby volunteer to do that. :-) > Going back to -exec-continue, it's > probably best to make it behave the same way as "continue", in non-stop > mode. This means that a frontend will have to conditionally pass "--all" to > -exec-continue, but in any way, if a frontend enables non-stop mode, is > surely has to adjust some of the logic, and changing -exec-continue logic > does not seem too hard. > Exactly. It's the same amount of work for a frontend writer either way. If "-exec-continue" (without parameters) resumes all: The frontend has to add new "resume one thread only button", which calls "-exec-continue --thread=x". The current "resume" button, already calling "-exec-continue", would resume all threads. If "-exec-continue" (without parameters) resumes only current thread: The frontend has to add new "resume all threads" button which calls "-exec-continue --thread=all". The current "resume" button, already calling "-exec-continue", would resume only the current thread. It's the same amount of work for a frontend writer, because he'd have to write support for one of the new buttons. In an hypothetical world, where one could only have access to one of these buttons, the most useful and general would be the "resume (current thread)" one. This means, that if the frontend writer is lazy, it's better this way :-) In my simplistic view of the frontend's world, I'd imagine that since there's a *running notification telling the frontend which threads resumed, the button actions doesn't have to care much which of the behaviours (one thread or all-threads) it is triggering. It's the notification callback that has to care. Thanks, -- Pedro Alves