Re: RFA [threads]: Thread cache

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Jan 11, 2003 at 01:13:55PM +0100, Mark Kettenis wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > I've figured out how to fix print-threads.exp (see my ramblings on gdb@
> > yesterday for a bad description of the problem; better coming soon). 
> > However, to do it, I discovered that it was actually _required_ that we
> > cache certain information from libthread_db, instead of merely beneficial.
> >
> > So I implemented the cache.  This patch is the entire cache mechanism,
> > except for updating the comment at the top of the file saying we need one.
> > Before I get to the patch itself, some numbers:
> 
> This looks good!  Please check it in, regardless of the things I say
> further on in this message.
> 
> > Now, on to the patch itself.  I replace all calls to td_ta_map_id2thr_p
> > and most calls to td_thr_get_info_p [Hmm, I don't see any reason not to
> > convert the others too; I will do that in a separate patch if this one is
> > approved, and see how much more it takes off the runtime] with calls to
> > wrapper functions which cache the data in the struct private_thread_info.
> > The cache is invalidated at every resume(); there's some information that we
> > could keep if we are guaranteed a 1-to-1 threads implementation with no
> > migration, like LinuxThreads or NPTL, but I'm being conservative for now.
> 
> Note that the thread_db.h interface provides TD_SWITCHTO and
> TD_SWITCHFROM events.  I'd be perfectly happy if you'd cache info
> about the LWP a particular user-level thread is bound to if you'd
> invalidate this info upon receiving those events (which should never
> happen in a 1-to-1 threads implementation.
> 
> That said, would re-enabling TD_DEATH events somehow make things more
> robust for you?  TD_DEATH was broken in glibc 2.1.3, but anybody who's
> doing any serious threads development should be using a more recent
> glibc.

I don't think that TD_DEATH would solve the problem.  Let me check when
they're actually delivered... no, TD_DEATH is reported immediately
before the terminated flag is set, i.e. the thread becomes a "zombie". 
The problem is that we need to continue debugging the thread until it's
actually _gone_.  Hmm, enabling TD_DEATH might be useful in that it
would simplify the ad-hoc-ness of the zombie handling; it could prevent
having to iterate over all LWPs, which would be nice.  I'll thik about
it.

Now, relying on SWITCHTO/SWITCHFROM has some potential.  The difficulty
is that using them would slow down debugging of a M-to-N implementation
substantially, I wager.  But we could at least do something like "assume
1-to-1 for caching purposes until we get a SWITCHTO/SWITCHFROM".  Hmm,
I need to think about that too.

Is there formal documentation for the libthread_db interface somewhere? 
Glibc certainly doesn't have any.  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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer