RE: info thread

[Alain Magloire <alain@qnx.com>]

> From: Denis PILAT [mailto:denis.pilat@st.com]
> Sent: Wednesday, September 27, 2006 10:18 AM
> To: Alain Magloire
> Cc: Daniel Jacobowitz; nickrob@snap.net.nz; gdb@sourceware.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.