This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
libthread_db thread handles
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Snyder <msnyder at redhat dot com>, Roland McGrath <roland at redhat dot com>,Ulrich Drepper <drepper at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 14 Jan 2003 17:46:41 -0500
- Subject: libthread_db thread handles
- References: <20030110204624.GA32002@nevyn.them.org> <86wulbc29o.fsf@elgar.kettenis.dyndns.org> <20030113214916.GA18517@nevyn.them.org> <3E235404.45568034@redhat.com> <20030114002758.GA30705@nevyn.them.org> <3E24901B.4841796E@redhat.com>
On Tue, Jan 14, 2003 at 02:32:59PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >
> > On Mon, Jan 13, 2003 at 04:04:20PM -0800, Michael Snyder wrote:
> > > Daniel Jacobowitz wrote:
>
> > > > For instance, I'd like to know if I
> > > > can safely cache the thread handles across resumes; if I could, this
> > > > would be much much much much easier to do efficiently. We could get
> > > > the thread handle and LWP when the thread is created, and then hold the
> > > > thread handle, and optionally hold the LWP. I am pretty sure this is
> > > > safe given glibc, but I don't know in general.
> > >
> > > I think in general not.
> >
> > Hmm. The Solaris documentation suggests that this is valid; I have no
> > way to check whether it actually is, and there is no explicit
> > description of the lifetime of a thread handle, but it doesn't describe
> > them as being of limited life. It's a handle to "the thread object"
> > itself.
>
> Dan,
>
> I passed your question along to Ulrich Drepper, and he says that,
> if by "thread handle" you mean the th_unique value, then yes,
> those are persistant until the thread exits. If you mean the
> td_thrhandle_t value, though, then no, they are not persistant.
> They are allocated by libthread-db as needed, then thrown away.
Eh? I'm a little thick-headed; Ulrich, could you explain to me what
you mean?
First of all, libthread_db doesn't necessarily create the
td_thrhandle_t; they're allocated by the caller of libthread_db, for
map_id2thr and map_lwp2thr. The iterators create them and then throw
them away, of course.
td_thrhandle_t is opaque; it is documented as opaque in <thread_db.h>.
I don't want to look at th_unique. Can I rely on the fact that the contents
of a td_thrhandle_t are stable and can be re-used if I save the
td_thrhandle_t?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer