Re: [PATCH RFA/RFC] Don't use lwp_from_thread() in thread_db_wait()

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Mar 11, 2002 at 08:16:19PM -0700, Kevin Buettner wrote:
> I think that an LWP id cache is only useful so long as all of the
> threads are stopped.  This is because the mappings could change in the
> course of running the program.  So, for this particular case, where
> the threads are running and we want to wait for one of them to stop,
> the cache wouldn't be useful to us.
> 
> Of course, if we have knowledge that a particular thread
> implementation never changes its mappings or perhaps only changes its
> mappings for certain threads, we might be able to use such a cache
> across the stop/start transitions.  However, I think that Mark had
> intended for thread-db.c to be a fairly generic solution that's not
> wedded to any one particular thread implementation.  In particular, it
> should be possible to use it with an M:N model in which a thread may
> migrate from one LWP to another.

This implies that part of the caching should be in lin-lwp.c rather
than in thread-db.c... that knowledge belongs with the lower level
threading layer.  Does that make sense?

We could also, for instance, update the cache via thread event
reporting...

> That said, the LWP<->TID mapping operations are farily expensive
> (since they involve fairly sizable target memory reads), and I agree
> that an LWP cache would be beneficial even if it needs to be
> invalidated when the program starts again.

Definitely.  I profiled this segment of GDB once not long ago; this and
the is_alive checks dominated the profile.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer