From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24646 invoked by alias); 2 May 2008 11:51:46 -0000 Received: (qmail 24636 invoked by uid 22791); 2 May 2008 11:51:45 -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 11:51:27 +0000 Received: (qmail 21645 invoked from network); 2 May 2008 11:51:25 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 May 2008 11:51:25 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: [RFA] Make continuations per-thread. Date: Fri, 02 May 2008 11:51:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sourceware.org, Daniel Jacobowitz References: <200804242045.39246.vladimir@codesourcery.com> <20080502030012.GB28580@caradoc.them.org> <200805021234.12472.pedro@codesourcery.com> In-Reply-To: <200805021234.12472.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805021551.11725.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/msg00069.txt.bz2 On Friday 02 May 2008 15:34:11 Pedro Alves wrote: > A Friday 02 May 2008 04:00:12, Daniel Jacobowitz wrote: > > On Thu, Apr 24, 2008 at 07:45:38PM +0300, Vladimir Prus wrote: > > > Right now, continuations are global. This means that if we're doing > > > 'finish' in one thread, then we cannot do 'finish' or anything that > > > also uses continuations, in any other thread. This seems unnecessary > > > limitation, and this patch makes continuations per-thread. > > > > > > Further into non-stop series, it really allows me to do 'finish' or > > > 'step' in several threads independently. > > > > > > OK? > > > > Could you explain why this is safe? We will do continuations for the > > thread which reports an event only. So it seems like continuations > > for other threads will linger in their struct thread. > > > > For example, if we finish from one thread and hit a breakpoint in > > another thread before the finish returns. > > That's true. Attached is what we have next on the non-stop > series to fix that. I'm not thrilled by it, but there are intermediate > context switches in handle_inferior_event that make it much uglier to try > 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 > using previous_inferior_ptid, which would be a good candidate, but I have > other plans for it. 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. - Volodya