List Info

Thread: inconsistency in thread naming




inconsistency in thread naming
user name
2007-11-21 18:23:06
When gdb switches to a particular thread it prints something
like

[Switching to Thread 12345]

But the "thread" command takes thread numbers,
e.g.

(gdb) thread 3

This inconsistency is a pain.  Any objections to making
things more
consistent?  Any opinions on how this should work?  A
minimalist
solution might be to include the thread number (3 in the
above
example) in the [Switching to ...] message.  If there was a
consistent
way to distinguish thread number(3) from thread id(12345)
[apologies
if my terminology if wrong], then the "thread"
command could take
either.  E.g. one might support "thread 3" or
"thread #12345".  I
don't have a strong opinion on what to choose, I'm just
thinking out
loud.

Re: inconsistency in thread naming
country flaguser name
United States
2007-11-26 13:08:43
On Wed, 2007-11-21 at 16:23 -0800, Douglas Evans wrote:
> When gdb switches to a particular thread it prints
something like
> 
> [Switching to Thread 12345]
> 
> But the "thread" command takes thread
numbers, e.g.
> 
> (gdb) thread 3
> 
> This inconsistency is a pain.  Any objections to making
things more
> consistent?  Any opinions on how this should work?  A
minimalist
> solution might be to include the thread number (3 in
the above
> example) in the [Switching to ...] message.  If there
was a consistent
> way to distinguish thread number(3) from thread
id(12345) [apologies
> if my terminology if wrong], then the
"thread" command could take
> either.  E.g. one might support "thread 3" or
"thread #12345".  I
> don't have a strong opinion on what to choose, I'm just
thinking out
> loud.

I see that you understand the context.  There are two ways
to 
identify a thread -- the "native" way, with an ID
that is 
assigned by the native system (a process id, LWP id, or
whatever),
and the gdb internal way, with a small counting integer
starting
with 1.  The gdb-assigned thread ids are analogous to
breakpoint
ids, and are much easier to type.

All gdb commands take the counting-integer-type thread ids
as arguments.

I think both of your suggestions are good:
(1) Identify the internal thread ID in the "Switching
to"
and "New Thread" messages.
(2) Provide a syntax (eg. prefix character) with which the
user may use the native thread id instead of the gdb thread
id as a command argument.

By the way, "info threads" is your interface for
discovering
the mapping between gdb thread id and native thread id.

Cheers,
Michael




[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )