Re: RFC: Re: [patch] Fix for 'info threads' crashes if zombie threads exist

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jul 13, 2006 at 08:49:52PM +0200, Mark Kettenis wrote:
> Probably a good idea, given the fact that it's unlikely we'll see a
> N:M threads library on Linux is the near future.

Exactly.  I've already removed functional M:N support in the interest
of improving the 1:1 support we're actually using; these are some of
the remaining vestigal bits.

> > It also (long overdue) removes the dependence on fill_gregset, and
> > removes a not especially useful call into libthread_db for converting
> > threads to strings.  There are a number of more possible cleanups,
> > but this hits the big ones.
> 
> Doesn't your simplification of thread_db_pid_to_str() lose some useful
> information about the extra system thread that the LinuxThreads
> library used to have (I'm not sure if that wart is still present in
> NPTL)?

It's not still present in NPTL.

It doesn't actually lose anything about the manager thread, because we
were never providing any in the first place.  We were only checking the
thread state, and the manager would always be TD_THR_ACTIVE.  That was
really only useful on platforms which did use the other states, like
STOPPED and SLEEP, but LinuxThreads didn't.

Such information might have been handy - but we don't have any reliable
way to identify the manager thread :-(

> You might want to look at implementing to_extra_thread_info() to give
> some state information; see bsd-uthread.c for an example.

... and in any case that's a better place for the state information.
Nice.  Unfortunately we don't really have useful state bits.  I could
probably move the exiting/missing text there.  I'll keep that in mind
for a future update, thanks!

-- 
Daniel Jacobowitz
CodeSourcery