Re: [RFC/WIP PATCH 13/14] Make "thread apply all" only loop over threads in the current set

[Pedro Alves <pedro@codesourcery.com>]

On Tuesday 29 November 2011 21:47:09, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Pedro> This makes "thread apply all" only loop over threads in the current
> Pedro> set instead of always all threads.
> 
> It seems to me that "thread apply" already has a thread argument, which
> could be syntactically extended to cope with sets:
> 
>     thread apply [1.*] print x
> 
> Then I think the existing syntax can just be mapped to a set:
> 
>     thread apply 1 2 3 print x
>  => thread apply [1,2,3] print x
> 
>     thread apply all print x
>  => thread apply [*] print x
>     (I didn't read the itset patch yet so I don't know if this is still
>     the right syntax, but you get the idea.)
> 
> If you considered this and rejected it, I would be interested in your
> reason.
> 
> I am not strongly wedded to this idea.
> 
> I wonder if your idea might be confusing for users, since "all" is an
> absolute word, but this patch makes it not so.

Yeah.  In a way, it's still "all" something.  But instead of
all in the debug session, it's "all" in current focus.  It's
a similar change as done to, e.g., "continue -a", where -a means "all
in current focus".  I actually tried out the change after finding this:

 http://sourceware.org/ml/gdb/2010-09/msg00035.html

"(...) a "upcmode" of operation where commands like breakpoint, info threads, .. apply
only to UPC threads (a set in your example). Also, "c -a" like commands apply only
to UPC threads. Same with "thread apply all". In essence you are focusing your
debugging to a group of threads. Switching off "upcmode" makes everything go back
to normal (in your case selecting a thread set "all" turns off this feature)."

and thinking that such upcmode could easily be reimplemented this way.
But I only now notice that they also change "info threads".  Hmm.
I'm dropping this patch for now.

> 
> Pedro> I think it might make sense to make "info threads" only list threads
> Pedro> of the current focus too.  WDYT?
> 
> If a command can determine whether it has an explicit prefix (and TBH I
> am not sure it is a good idea to allow this -- and I didn't read that
> patch yet either) 

I don't think that is a good idea either.

> If there is a set meaning "the current focus set" you could:
> 
>    [1.*]> [$] info thread
> 
> ... giving the current set some short moniker like "$" makes it easier
> to use.

That one I think makes sense.  I implemented it for experimentation.

> "info thread" takes thread arguments, so perhaps the same rewriting idea
> used above applies.  This approach would work even without a command
> knowing whether it has explicit context:
> 
>   (gdb) info thread 1 2 3
>   => info thread [1,2,3]
> 
>   (gdb) info thread [$]
>   => focused threads
> 
>   (gdb) info thread [1.*]
>   => threads of inferior 1

This may be what makes most sense.

-- 
Pedro Alves