From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-64965-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 27263 invoked by alias); 29 Jun 2009 21:42:29 -0000
Received: (qmail 27253 invoked by uid 22791); 29 Jun 2009 21:42:28 -0000
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 21:42:20 +0000
Received: (qmail 8215 invoked from network); 29 Jun 2009 21:42:19 -0000
Received: from unknown (HELO orlando.local) (pedro@127.0.0.2)   by mail.codesourcery.com with ESMTPA; 29 Jun 2009 21:42:19 -0000
From: Pedro Alves <pedro@codesourcery.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [patch] Fix internal-error on dead LWPs with no associated thread
Date: Mon, 29 Jun 2009 21:42:00 -0000
User-Agent: KMail/1.9.10
Cc: gdb-patches@sourceware.org
References: <20090629100922.GA26882@host0.dyn.jankratochvil.net> <200906291941.52129.pedro@codesourcery.com> <20090629213333.GA3295@host0.dyn.jankratochvil.net>
In-Reply-To: <20090629213333.GA3295@host0.dyn.jankratochvil.net>
MIME-Version: 1.0
Content-Type: text/plain;   charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200906292243.24272.pedro@codesourcery.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2009-06/txt/msg00852.txt.bz2

On Monday 29 June 2009 22:33:33, Jan Kratochvil wrote:
> I do not share this opinion - not attaching short-lived threads should no=
t be
> allowed for performance reasons. =A0When such short-lived thread crashes =
GDB
> should catch such crash.
>=20

Sorry, this makes no sense.  GDB is automaticaly attached to cloned
threads.  You won't miss any crash.  You're thinking of discovering
threads with thread_db?

The performance issue is related with communicating the
new-thread/thread-exited to the frontend, or with printing it to
the screen with printf_unfiltered, not related to the thread
management per-se.

--=20
Pedro Alves