From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10140 invoked by alias); 1 Jul 2008 14:03:38 -0000 Received: (qmail 10129 invoked by uid 22791); 1 Jul 2008 14:03:37 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 01 Jul 2008 14:03:14 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 791B098413; Tue, 1 Jul 2008 14:03:12 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 2C92998243; Tue, 1 Jul 2008 14:03:12 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KDgRr-00086c-Ih; Tue, 01 Jul 2008 10:03:11 -0400 Date: Tue, 01 Jul 2008 14:03:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [non-stop] 10/10 split user/internal threads Message-ID: <20080701140311.GA30550@caradoc.them.org> Mail-Followup-To: Pedro Alves , gdb-patches@sourceware.org References: <200806152209.45049.pedro@codesourcery.com> <200806300108.49392.pedro@codesourcery.com> <20080701005128.GA10432@caradoc.them.org> <200807011437.45222.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807011437.45222.pedro@codesourcery.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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-07/txt/msg00005.txt.bz2 On Tue, Jul 01, 2008 at 02:37:44PM +0100, Pedro Alves wrote: > A Tuesday 01 July 2008 01:51:28, Daniel Jacobowitz wrote: > > On Mon, Jun 30, 2008 at 01:08:48AM +0100, Pedro Alves wrote: > > > - In non-stop mode, the current thread may exit while the > > > user has it selected. Switching current thread, and restoring > > > it with a cleanup is problematic in non-stop mode. > > > > The target interface is async, the inferior program is running - but > > GDB retains a single thread of control. So unless the inferior runs > > while the cleanup is live, there's no problem here. I suppose it > > could be trouble if you enter the expression evaluator, though? > > Sure it can run while the cleanup is live. It could already be > running when the cleanup was created. Remember that the selected > thread may be running at any time. Doesn't matter if the thread is already running. We won't go looking for events while normal cleanups are on the stack in most cases - so even if the thread exits, we won't remove it from the thread list until later. But the evaluator, and some commands, might cause us to return to w_f_i. That's all I meant. > The user loses the selected frame in thread 1, because when > the cleanup is ran, the thread is running/stepping. > Since the thread stepped into another frame, we could > claim that since the originally selected frame is still live, > it should still be selected. But, it can also be > claimed that, though luck, the thread was set running, > you lose the selected frame. This doesn't seem > like an important enough case to care about. Agree? Agreed. We can worry about it later. Execution commands in commands lists already behave weirdly - e.g. they may cause the rest of the command list to be discarded. > There's one issue that I'd like to point out. That is, is a > thread exits, and it was inferior_ptid, we can't just switch > inferior_ptid to null_ptid as I could with split user/internal > threads split. A *lot* of things break. > > The issue arises with the OS quickly reusing ptids: > > - inferior_ptid (ptid1) exits, we can't delete it from the > thread list yet (things break, e.g. context switching..., > but many other things break in target code.) > - We mark it with THREAD_EXITED, but leave it there. > - target notifies new thread with ptid1. There's already > such a thread in the list, and it's also the > current thread -- inferior_ptid. > - To add this new thread to the list, we must get rid > of the old exited thread. Conceptually, this new thread > although it has the target identifier, it should have a > new GDB thread id. So, we could say that in this case, > the "non-stop doesn't change threads" premise breaks. But, > then again, the user couldn't do anything to the exited > thread anyway, and it can only exit is it is running, in which > case the user also couldn't do most things with it. Maybe we > can just live with this exception. IMO, as long as GDB is not likely to crash, I don't think there's a big problem here. If we, for instance, fail to report one pair of thread exit and thread creation events in this case that would be OK. Any number of other quirky behaviors would too. Most systems have a sufficiently large ID space and avoid immediate reuse such that this is very unlikely to ever trigger. If we come across a system that reuses the first available TID then we'll have to do better but we'll also have an easier way to test :-) Is this patch a blocking issue for the other non-stop patches, or would you like to start merging them? Also, a request: I know that you and Vlad are going to be filling in the documentation and test cases before any release goes out with this code. In the meanwhile, could you create a wiki page listing things to be documented/tested so that there's a single central list? -- Daniel Jacobowitz CodeSourcery