Re: [rfa] Include the LWP in thread-db's PTIDs

[Daniel Jacobowitz <drow at false dot org>]

On Wed, Oct 13, 2004 at 05:27:15PM -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 13, 2004 at 11:16:05PM +0200, Mark Kettenis wrote:
> >    Date: Tue, 12 Oct 2004 09:31:40 -0400
> >    From: Daniel Jacobowitz <drow@false.org>
> > 
> >    On Mon, Oct 11, 2004 at 09:40:26PM +0200, Mark Kettenis wrote:
> >    > 
> >    > I think assuming 1:1 threads is fair enough.  But Daniel, if you're
> >    > going to do that, I'd like to ask you to rename thread-db.c into
> >    > linux-thread.c or something like that.
> > 
> >    How about glibc-thread-db.c?
> > 
> > I'm not sure whether that's appropriate.  NPTL is defenitely
> > Linux-specific.  The Hurd doesn't have a thread_db yet.  I suppose
> > that if you're going to make some Linux-specific assumptions
> > glibc-thread-db.c isn't right.
> 
> I was not planning on making any Linux-specific assumptions in the
> thread-db code - just in lin-lwp.  I doubt glibc's thread_db
> implementation is going to support non-1:1 threading, and that's the
> only assumption I am planning on using in what is now thread-db.c.
> 
> But I don't know much about threading for the only active non-Linux
> users of glibc (the kBSD projects and the Hurd).  Do you think that the
> 1:1 assumption is Linux-specific rather than glibc-specific?  If so,
> linux-thread-db.c would be a better choice indeed, and I can use that.

Ping on the renaming question.

I think that I should take care of the renaming of this file before I
start adding assumptions to it, so I withdraw the patch at the
beginning of this thread until that has been taken care of.

> >    Anyway, I'm wondering if there should be some other method of
> >    communication between the native and thread strata (as opposed to
> >    between lin-lwp and thread_db!).  I don't much want to use to_wait for
> >    this, because the assumption in the rest of GDB is that to_wait returns
> >    when all threads are stopped and I don't want to gratuitously stop all
> >    threads when we receive a creation event.
> > 
> > But you don't have to return from to_wait upon a creation event.  But
> > we probably should if the user asks us to report new threads.  The
> > current way of printing [new thread] messages is a bit broken, since
> > GDB doesn't always have control over the terminal.
> 
> Indeed, we don't have to return from to_wait after thread creation. 
> However, if there are thread strata above us, we want to report the new
> thread to them promptly.  For instance, the thread-db layer should
> always (when in use) sit between lin-lwp and GDB for thread reporting,
> so that threads are reported with the correct TID.
> 
> [It's a little more complicated than that, in this case.  The TID is
> not available quite as early as the LWP is, so we have the LWP without
> its corresponding thread.  So GDB might have to handle the thread IDs
> changing during its lifetime; ew.]

I'm still thinking about this bit...

-- 
Daniel Jacobowitz