info thread

> From: Denis PILAT [mailto:denis.pilatst.com]
> Sent: Wednesday, September 27, 2006 10:18 AM
> To: Alain Magloire
> Cc: Daniel Jacobowitz; nickrobsnap.net.nz; gdbsourceware.org
> Subject: Re: info thread
> 
> 
> 
> Alain Magloire wrote:
> 
> >
> >>I think you're thinking of -thread-list-ids. 
Ah, this is mi/674.
> >>It's also mi/1040.  Both of which suggest
*stopped 
> >>
> >>We could add the thread to -thread-list-ids,
too.
> >>
> >>Something to keep in mind: the thread
"extra info" is expensive to
> >>collect on some platforms, e.g. requires asking
the remote stub for
> >>details on each individual thread.
> >>
> >>
> >
> >Noted, but some platforms put some extra stuff in
the output of "info
> >threads" like thread names, states, mutexes
etc ... this information is
> then
> >retrieve by the IDE and shownn to the user.
> >
> Yes but to display this "extra stuffs" they
have to customize their
> Eclipse (or any UI) to implement a parser for that.
> 
> I think it will be more generic and cost less (in term
of execution
> time) if "extra information" could be
accessible thru an other mi
> command than -thread-list-ids.
> Generic part of the UI then calls -thread-list-ids
> Targets that want to display more information then just
call a more
> complete command like -thread-list-all-threads
> or -thread-info on each thread.
> 
> 

Agreed, if we the UI views are smart enough to tell which
threads are
visible to the users then the implementation can be lazy in
getting the
info.

> What I propose is the following:
> 
> -thread-list-ids :
> INPUT: none
> OUTPUT:
>     o list of IDs
>     o Current thread could be the first (or last) item
of the list, or
>     warned by an asterisk
> 
> -thread-list-all-threads
> INPUT: none
> OUTPUT:
>    o like  -thread-list-ids
>    o plus the list of "extra information" per
thread
> 
> 
> -thread-info
> INPUT: thread ID as an optional parameter, if not given
the following
>     concerns current thread
> OUTPUT:
>     o thread ID (could be used to determine which is
the current
>     thread if not given in parameter)
>     o extra information
>     o stack frame
> 
> 

OK.  And in term of format, are we talking tuple/list? 
There was some
inconsistencies in the old MI versions.  Also for extra
information you are
probably mean "optional extra information" will
that be an opaque string or
name=value pairs.

> 
> Apart from the debate let me give you some measurements
I did on a
> 100 threads program that runs on a board, debugged thru
jtag.
> Figures for the "info thread" CLI command
only:
> 70 % of the time is spent in getting the stack frame
for all threads
> 1% on the "extra info"
> 29% on other stuff out of the loop that collect thread
above information.
> 
> Stack frame is the one that takes the most since it
requires to switch
> the current thread and print the stack. Switching takes
60% of that
> time. Moreover extra information are reduced for our
target.
> 
> Please note that the total time is 7.2 seconds for this
example !

On some architecture "info threads" can make
things extremely slow, since
the IDE will have to poll at every step to discover
created/destroyed
threads.  For the long run we should probably look at
notifications.