Re: thread id is lost when viewing list of threads in slickedit

[Jon Ringle <jon.ringle@comdial.com>]

On Friday 23 September 2005 03:57 pm, Daniel Jacobowitz wrote:
> On Fri, Sep 23, 2005 at 03:38:36PM -0400, Jon Ringle wrote:
> > CC'ing gdb mailing list this issue. It seems that via the MI interface
> > thread ID information is lost. Is there any way from the MI interface to
> > get the thread IDs that seem to be missing?
>
> The thread ID is not the third word, it's everything from the thread
> number to the thread PC.  They're freeform, depending on the target, et
> cetera.  So it's "thread 8201" and GDB tries to give you something
> useful.

Well, it certainly is useful when debugging a deadlock. As long as a mutex is 
initialized as a recursive type, then if a deadlock occurs in an app, I can 
attach to the process and look for threads that are waiting for a mutex. Then 
I can find out the thread that currently owns the mutex that this thread is 
waiting for by printing:
	*((int*)(mutex.__m_owner) + 4)

This seems to work at least with linuxthreads.

> If you upgrade to NPTL, you'll find they get a lot less 
> intelligible.

As long as they are unique and I can track them somehow in code, then it 
doesn't matter too much to me.