From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6587 invoked by alias); 2 May 2008 13:30:58 -0000 Received: (qmail 6572 invoked by uid 22791); 2 May 2008 13:30:57 -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:30:39 +0000 Received: (qmail 24869 invoked from network); 2 May 2008 13:30:37 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 May 2008 13:30:37 -0000 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: [RFA] Make continuations per-thread. Date: Fri, 02 May 2008 13:30:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: Pedro Alves , gdb-patches@sourceware.org References: <200804242045.39246.vladimir@codesourcery.com> <200805021234.12472.pedro@codesourcery.com> <20080502132337.GA29202@caradoc.them.org> In-Reply-To: <20080502132337.GA29202@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805021730.33831.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/msg00072.txt.bz2 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? 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? - Volodya