From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-11937-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 26015 invoked by alias); 15 Jan 2003 00:16:50 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 25970 invoked from network); 15 Jan 2003 00:16:48 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by 209.249.29.67 with SMTP; 15 Jan 2003 00:16:48 -0000
Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h0ENmLB01218
	for <gdb@sources.redhat.com>; Tue, 14 Jan 2003 18:48:21 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0F0GYn24865;
	Tue, 14 Jan 2003 19:16:34 -0500
Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h0F0GYE30624;
	Tue, 14 Jan 2003 16:16:34 -0800
Message-ID: <3E24A862.108D36E3@redhat.com>
Date: Wed, 15 Jan 2003 00:16:00 -0000
From: Michael Snyder <msnyder@redhat.com>
Organization: Red Hat, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: Roland McGrath <roland@redhat.com>
CC: Ulrich Drepper <drepper@redhat.com>, Daniel Jacobowitz <drow@mvista.com>,
   gdb@sources.redhat.com
Subject: Re: libthread_db thread handles
References: <200301142346.h0ENkp512697@magilla.sf.frob.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2003-01/txt/msg00252.txt.bz2

Roland McGrath wrote:
> 
> > If you have the pthread_t value computing the td_thrhandle_t is an
> > operation which can be performed entirely without the looking at the
> > inferior.  At least in the new implementation.  Just call
> > td_ta_map_id2thr().  This shouldn't add any measurable overhead.
> >
> > I would prefer you caching the pthread_t value very much over caching
> > any opaque data structure.  If this means adding a function
> > td_ta_map_thr2id() I'd have no problems with it.  But not even this
> > should be necessary since for both events, TD_CREATE and TD_DEATH, the
> > eventdata is the pthread_t value.  And this should be a documented
> > interface.
> 
> One can already use td_thr_get_info and ti_tid is the pthread_t value (that
> can be given to td_ta_map_id2thr).

That's much better than using thr_unique.