Re: info thread

[Daniel Jacobowitz <drow at false dot org>]

I really wish the same set of people read both this list and
cdt-debug-dev, or even cdt-debug-dev and dmi-discuss if that's
more appropriate... I keep ending up saying the same thing on both :-)
And my message to cdt-debug-dev isn't in the web archive yet.

On Mon, Sep 25, 2006 at 01:27:41PM -0400, Alain Magloire wrote:
> It is my understanding, that the output is platform dependent. Are you
> suggesting a new command to retrieve this info? I was hopping we could stuff
> this in the output of -thread-list-ids.
> 
> Basically, we would like to retrieve more information on a thread what is
> the best way for MI?

I wrote:

There are, in the GDB manual, three related commands: -thread-info
(unimplemented), -thread-list-all-threads (unimplemented), and
-thread-list-ids.  What I've been asking on the GDB list is which
information is useful for -thread-list-all-threads versus -thread-info.
Collecting data like "is this thread interruptible" is definitely
important and GDB has a mechanism for it already.  But you have to
do round trips with the target to get this sort of thing.  And
currently you have to do that for the OS name too when talking
to a remote target.

So: is there a useful middle ground between -thread-list-ids
(definitely shouldn't return it) and -thread-info (definitely
should) for -thread-list-all-threads to fill?  Or should we just
do one at a time, and let e.g. the client request extra info
on specific threads which are currently visible in a scrolling
pane?

In the mean time, I think that implementing -thread-info and
adding the current thread to -thread-list-ids are both useful.



Pawel's just responded:

I see what you're getting at.  My intent is to take advantage of
lazy-loading and only request thread-info for threads that are visible
in the UI.  But even then, requesting information for 20 or so threads
one at a time could be painfully slow.  So if -thread-list-all-threads
were to return the same info as -thread-info, and if it took a list of
thread IDs as an optional argument, that would solve this problem
perfectly.


Alain, Denis, what do you think?

-- 
Daniel Jacobowitz
CodeSourcery