From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6647 invoked by alias); 19 Mar 2008 19:38:09 -0000 Received: (qmail 6636 invoked by uid 22791); 19 Mar 2008 19:38:06 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 19 Mar 2008 19:37:44 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 97E703C6E1; Wed, 19 Mar 2008 12:37:42 -0700 (PDT) Subject: Re: MI non-stop mode spec From: Michael Snyder To: Nick Roberts Cc: Vladimir Prus , gdb@sources.redhat.com In-Reply-To: <18400.55659.354715.462161@kahikatea.snap.net.nz> References: <200803190016.02072.vladimir@codesourcery.com> <18400.32557.752481.709565@kahikatea.snap.net.nz> <18400.55659.354715.462161@kahikatea.snap.net.nz> Content-Type: text/plain Date: Wed, 19 Mar 2008 20:44:00 -0000 Message-Id: <1205955462.19253.997.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00164.txt.bz2 > > Note that current thread.c implementation will only declare a thread as done > > when we do -thread-info (or anything else that calls prune_threads, so the > > value of =thread-exited will be limited, without some associated work on > > threads layer). > > I'm not sure what you mean. If I run Gdb normally with a multi-threaded > application, I get: > > [New Thread -1210639472 (LWP 7235)] > > when a thread is created and: > > [Thread -1210639472 (LWP 7235) exited] > > when it is terminated. This is historical. In the earliest gdb thread debugging implementations, there was no notification on thread exit, and gdb only removed a thread from its internal list when prune_threads was called (which was usually on the "info threads" command). More recently, we have SOME thread debugging interfaces that give us a thread exit notification, but we retain the prune_threads mechanism as insurance. So, depending on whose threads you are using, you may be able to detect thread exit when it happens, or you may not.