This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>>>>> "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.

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) then you could have it use the current focus if and
only if the focus is explicit.

That is:

   [1.*]> info thread
   => all threads

   [1.*]> [1.*] info thread
   => just threads in inferior 1

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.


"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


In any case if these commands respect the focus set, then we also have
to define what happens if they are passed explicit threads.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]