From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14910 invoked by alias); 2 May 2008 13:46:15 -0000 Received: (qmail 14898 invoked by uid 22791); 2 May 2008 13:46:14 -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 13:45:56 +0000 Received: (qmail 25711 invoked from network); 2 May 2008 13:45:54 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 May 2008 13:45:54 -0000 From: Pedro Alves To: Vladimir Prus Subject: Re: [RFA] Make continuations per-thread. Date: Fri, 02 May 2008 13:51:00 -0000 User-Agent: KMail/1.9.9 Cc: Daniel Jacobowitz , gdb-patches@sourceware.org References: <200804242045.39246.vladimir@codesourcery.com> <20080502132337.GA29202@caradoc.them.org> <200805021730.33831.vladimir@codesourcery.com> In-Reply-To: <200805021730.33831.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805021445.52210.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00077.txt.bz2 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? 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. -- Pedro Alves