RFC: using Ada tasks numbers with thread commands

RFC: using Ada tasks numbers with thread commands

[Joel Brobecker]

Hello,

Philippe and I were discussing how some Ada task commands, and
the lack of support for some functionalities that we have for
thread commands. For instance, we have "thread apply ...", and
Ada users usually prefer to iterate over Ada tasks rather than
threads.

I was ready to work on implementing equivalent Ada commands, but
Philippe instead suggested that we just enhance the thread ID parsing
routines to recognize a special syntax that would signify the ID
is not a thread, but rather an Ada task. For instance, Philippe
suggested something like adding a 't' suffix (eg: 5t); I could
imagine something like 'a' for "Ada" instead, as 't' can be both
"thread" and "task", and we could play with making it a prefix
instead (eg: "a5"). So, existing thread commands would automatically
be able to handle Ada task numbers also. Eg:

    (gdb) thread apply 5a-7a bt

What do you guys think of the idea?

On my end, I have to say I have some reservations about this;
for a single Ada task, why not indeed; but for a range of tasks,
there is no guaranty that a range of Ada tasks maps to a range of
threads; nor that Ada tasks are going to be listed in the same
order as threads.

That being said - if people are OK with the syntax above, I think
the issues I listed can be easily dealt with, but having the thread
ID parser expand the range into a list.

But thinking out loud - what if the user used a hybrid range? Would
that make any kind of sense? If yes, how do you expand that, knowing
again that threads and Ada numbers do not necessarily have a linear
mapping. If feels like, at least to start with, we should not allow
that at all.

Thoughts?

-- 
Joel

Re: RFC: using Ada tasks numbers with thread commands

[Pedro Alves]

On 10/09/2018 03:09 PM, Joel Brobecker wrote:
> Hello,
> 
> Philippe and I were discussing how some Ada task commands, and
> the lack of support for some functionalities that we have for
> thread commands. For instance, we have "thread apply ...", and
> Ada users usually prefer to iterate over Ada tasks rather than
> threads.
> 
> I was ready to work on implementing equivalent Ada commands, but
> Philippe instead suggested that we just enhance the thread ID parsing
> routines to recognize a special syntax that would signify the ID
> is not a thread, but rather an Ada task. For instance, Philippe
> suggested something like adding a 't' suffix (eg: 5t); I could
> imagine something like 'a' for "Ada" instead, as 't' can be both
> "thread" and "task", and we could play with making it a prefix
> instead (eg: "a5"). So, existing thread commands would automatically
> be able to handle Ada task numbers also. Eg:
> 
>     (gdb) thread apply 5a-7a bt
> 
> What do you guys think of the idea?
> 
> On my end, I have to say I have some reservations about this;
> for a single Ada task, why not indeed; but for a range of tasks,
> there is no guaranty that a range of Ada tasks maps to a range of
> threads; nor that Ada tasks are going to be listed in the same
> order as threads.
> 
> That being said - if people are OK with the syntax above, I think
> the issues I listed can be easily dealt with, but having the thread
> ID parser expand the range into a list.
> 
> But thinking out loud - what if the user used a hybrid range? Would
> that make any kind of sense? If yes, how do you expand that, knowing
> again that threads and Ada numbers do not necessarily have a linear
> mapping. If feels like, at least to start with, we should not allow
> that at all.
> 
> Thoughts?
> 

That's quite similar to what I implemented in my getting-old
itsets branch ('t' for threads, 'c' for cores, 'i' for inferiors,
'a' for ada tasks), but after using it a while, I came to the
conclusion that it isn't a very good idea.  Ends up being confusing,
complicated, and not easy to use ("why do I have to type all these
'a's all the time??").

Thanks,
Pedro Alves