This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libthread_db thread handles


On Tue, Jan 14, 2003 at 03:00:58PM -0800, Roland McGrath wrote:
> > 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?
> 
> For the life of the td_thragent_t, yes.  That is, until there is a TD_DEATH
> event for the thread.  Once you resume the LWP that stopped to report the
> TD_DEATH event, any td_thrandle_t associated with the dying thread is
> invalid (as you would expect).  Since the closest thing to a spec for
> thread_db is the Solaris documentation, and that's vague, we can't quite
> say that this is "part of the spec".  But in extant GNU/Linux
> implementations it is certainly true, and I can't envision an
> implementation in which it would not be true.

Thank you.  That's exactly what I was trying to get.

We still need to hold onto the thread after TD_DEATH (or
pthread_detach'ing; we haven't really started handling that right
yet...) but at that point we don't need the td_thrhandle_t any more; we
can just track the LWP itself.

Michael/Mark: I can use this to be much more efficient in the caching. 
I'll get back to it when I have a chance to.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]