libthread_db thread handles

libthread_db thread handles

[Daniel Jacobowitz]

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

Re: libthread_db thread handles

[Roland McGrath]

> 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.

Re: libthread_db thread handles

[Daniel Jacobowitz]

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

Re: libthread_db thread handles

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Jacobowitz wrote:

> 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.

...which is why you cannot reply on the addresses of these objects to
have any relevance.  This is why I mentioned it.


> 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?

In the current implementation this is the case but I don't want to
commit to this unless you can show me there are big benefits.  It would
help if you could describe what functions you see being used often and
in which contexts.  There are things in the libthread_db implementation
which can be changed without breaking the ABI.  We just need to know how
you use the library.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+JJhk2ijCOnn/RHQRAivlAJ0V9WNF9X4Dus63bliLW8M42exPJwCgn/wa
yMXOoHldlHIHSL4Lq+rjIqA=
=ySWh
-----END PGP SIGNATURE-----

Re: libthread_db thread handles

[Daniel Jacobowitz]

On Tue, Jan 14, 2003 at 11:08:20PM +0000, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel Jacobowitz wrote:
> 
> > 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.
> 
> ...which is why you cannot reply on the addresses of these objects to
> have any relevance.  This is why I mentioned it.

OK.  I understand; I don't expect the addresses to be relevant.

> > 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?
> 
> In the current implementation this is the case but I don't want to
> commit to this unless you can show me there are big benefits.  It would
> help if you could describe what functions you see being used often and
> in which contexts.  There are things in the libthread_db implementation
> which can be changed without breaking the ABI.  We just need to know how
> you use the library.

To find the state of a thread, we need to first get a thread handle for
it and only then can we call td_thr_get_info.  I'd like to save a copy
of the td_thrhandle_t when we get the TD_CREATE event, and be able to
hand it to td_thr_get_info until I see a TD_DEATH event (can a thread
die without us getting the TD_DEATH event?  Is there some other thing
we should be watching for a thread to vanish?).

This can be a major timesaver, in addition to caching the LWP ID and
holding on to it as long as we know we've got a 1-to-1 mapping (via
not seeing any TD_SWITCHTO/TD_SWITCHFROM).

If you're not comfortable with it, let me know and I'll figure out
whether I can get the same effect another way.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: libthread_db thread handles

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Jacobowitz wrote:

> To find the state of a thread, we need to first get a thread handle for
> it and only then can we call td_thr_get_info.  I'd like to save a copy
> of the td_thrhandle_t when we get the TD_CREATE event,

The problem is calling the *_iter functions or so?

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.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+JKAK2ijCOnn/RHQRAkQPAJ4nWwjfiDFhbpMjooxuUEiH5Dc4pwCfT9La
XkXgLoaakbUo5xoO9YXRj1k=
=hQUV
-----END PGP SIGNATURE-----

Re: libthread_db thread handles

[Roland McGrath]

> 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).

Re: libthread_db thread handles

[Michael Snyder]

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.

Re: libthread_db thread handles

[Daniel Jacobowitz]

On Tue, Jan 14, 2003 at 03:40:54PM -0800, Ulrich Drepper wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Daniel Jacobowitz wrote:
> 
> > To find the state of a thread, we need to first get a thread handle for
> > it and only then can we call td_thr_get_info.  I'd like to save a copy
> > of the td_thrhandle_t when we get the TD_CREATE event,
> 
> The problem is calling the *_iter functions or so?
> 
> 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.

In the old implementation this isn't true; it does involve a memory
read.  I see that it's only one, though; I thought it was more.  We
certainly hold on to the pthread_t value already.  Maybe this isn't
necessary after all - I'll spend some more time working on the caching
and see what I need.  If map_id2thr does not require a memory read in
NPTL that is a further reason not to bother.

We don't need thr2id; td_thr_get_info gives it to us.

We've been avoiding using TD_DEATH events because they caused a crash
in threaded programs using old glibc versions.  Mark has suggested that
it's time to drop that requirement and just let those people use GDB 5.3.
That makes this simpler.  The original problem involved a workaround
for grossness involving debugging threads after their TD_DEATH event,
and it will be much easier if we receive the event.

Consider my request withdrawn.  I'll get back to you if we need more.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer