From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9942 invoked by alias); 2 May 2008 14:10:50 -0000 Received: (qmail 9931 invoked by uid 22791); 2 May 2008 14:10:49 -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; Fri, 02 May 2008 14:10:32 +0000 Received: (qmail 26659 invoked from network); 2 May 2008 14:10:29 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 May 2008 14:10:29 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: [RFA] Make continuations per-thread. Date: Fri, 02 May 2008 14:15:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: Daniel Jacobowitz , gdb-patches@sourceware.org References: <200804242045.39246.vladimir@codesourcery.com> <200805021730.33831.vladimir@codesourcery.com> <200805021445.52210.pedro@codesourcery.com> In-Reply-To: <200805021445.52210.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805021810.26615.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00082.txt.bz2 On Friday 02 May 2008 17:45:51 Pedro Alves wrote: > A Friday 02 May 2008 14:30:32, Vladimir Prus escreveu: > > On Friday 02 May 2008 17:23:37 Daniel Jacobowitz wrote: > > > On Fri, May 02, 2008 at 12:34:11PM +0100, Pedro Alves wrote: > > > > to not make it centralized. This is one of the things that gets much > > > > better looking when we switch completelly to always-a-thread, and > > > > get rid of context-switching. I'm introducing another variable, > > > > instead of > > > > > > So maybe we should do that in the FSF tree before the attached patch - > > > is that feasible? > > > > > > On Fri, May 02, 2008 at 03:51:10PM +0400, Vladimir Prus wrote: > > > > This is only for intermediate continations. For ordinary continuations, > > > > not running them when we hit a breakpoint in another thread is > > > > desirable. Why should a breakpoint in some other thread abort "finish"? > > > > Note that in current gdb, hitting a breakpoint in unrelated thread does > > > > not abort "next" -- say we did next, inserted step resume breakpoint, > > > > and then hit breakpoint in some other thread. Then, the step resume > > > > breakpoint will not be removed. If we decide to continue the program, > > > > we'll eventually hit it. > > > > > > > > I don't see any problem with continuations been kept for a given thread > > > > for a long time. It's not an unbounded amount of continuations -- if we > > > > get an event in this thread, continuation will run, and if we don't get > > > > an event, we won't add any futher continuations. > > > > > > In non-stop mode, the continuation will run the first time that thread > > > stops because threads only stop when there is an event. But in > > > all-stop mode the thread will be stopped with its continuations not > > > yet run. > > > > > > [Current thread is 1] > > > finish > > > [Switching to thread 2] > > > Breakpoint at.... > > > thread 1 > > > finish > > > > > > Now thread 1 has two finish continuations and they're at different > > > threads... is it going to do something sensible? What's sensible? > > > > Yes, this seems like a problem. The second finish command installs > the continuations in the last even thread. In non-stop, this is > fixed by making the thread command context_switch instead of just > switch_to_thread. Maybe that should be done in all-stop too? This sounds like a reasonable idea. > We'd context-switch to the last event thread when resuming, so > the right context is set to step over breakpoints etc. > > Then the question would be: > > Now thread 1 has two finish continuations in the queue. Shouldn't > the previous one be canceled? > > > I think the sensible behaviour is the same as for "next" -- abort > > whatever the operation we were doing. This means that we have to wipe > > continuation inside 'proceed'. I can adjust the patch this way, but > > does it make sense to you? > > > > Isn't that too late? When you get to proceed, the new finish > continuation is already installed. This is true. The clean solution, probably, is to add a check in each command that eventually calls proceed. If the per-thread state of the current thread records we're doing some operation, we should ask the user if he wants to actually abort that operation. I think we can actually find all the commands that proceed the targets, so this is doable, but is a bit of work, unfortunately. - Volodya