Re: [RFA] Add optional argument to "info threads" command

[Michael Snyder <msnyder at vmware dot com>]

Pedro Alves wrote:
> On Sunday 23 November 2008 02:12:52, Michael Snyder wrote:
> > I've long been frustrated because I could not ask for
> > info about just one or more threads.
> >
> > This patch makes use of command parsing code in breakpoint.c
> > to give "info threads" the same optional arguments as "info
> > breakpoints", ie. a list of one or more threads of interest,
> > or a range of threads (eg. "5-9").
> >
> >
> > OK?
>
> I'd like to point out that if you're debugging a multi-threaded
> application with lots of threads (the case where you'd want to use
> the range of threads feature), your implementation will, for
> each id in the specified range:
>
>  1. call prune_threads.
>
>     This is a bunch of T (thread alive) packets in the remote target,
>     one for each thread in the thread list -- not for each in
>     range, really *for all* threads.
>
>  2. call target_find_new_threads.
>
>     A bunch of qfThreadInfo packets.  One for *each remote thread*, not
>     just the ones specified in the range.
>
>  3. do a make_cleanup_restore_current_thread and restore
>     the selected thread and frame once for each thread in the
>     range.  This triggers about the double amount of registers
>     and memory reads than necessary.
>
>  4. also, there's a chance you'll hit the same warning in
>     restore_selected_frame once for each id in the range.
>
> If you consider remote targets, and thinking that this new
> feature would be most useful if you have many threads,
> points 1-3 above can be heavy against not so fast links.  I
> suggest abstracting out the bits in print_thread_info that do the
> actual printing from the bits that prune dead threads, find
> new threads, and restore the original selected frame.

Well, all your observations are correct -- but the same thing
also happens if you merely switch the thread of focus using the
"thread" command.

I do think that prune-threads and target_find_new_threads
are being called too aggressively from somewhere, but it
isn't directly from info_threads_command.

I think this is a separate, pre-existing problem that this patch
helps to reveal.