Re: MI non-stop interface details

[Pedro Alves <pedro at codesourcery dot com>]

Vladimir,

A Thursday 01 May 2008 18:21:51, Vladimir Prus wrote:

> [Pedro and I discussed this a bit on IRC, and...]
>
> On IRC, you said:
>
>    [20:40] <pedro> in CLI it's lame to have to know the thread id, and to
> have to pass it to "continue". [20:43] <pedro> break 20; <hit breakpoint>;
> next; next; <hits other bkreapoint in another thread>; another next; one
> step; continue; uuups, other thread resumed too...
>
> I think this is valid point -- if user, in CLI, enables non-stop, then
> having "continue" just work, resuming one thread, seems right. Are you
> going to add "--all" to "continue"?

Sure!  I hereby volunteer to do that.  :-)

> Going back to -exec-continue, it's 
> probably best to make it behave the same way as "continue", in non-stop
> mode. This means that a frontend will have to conditionally pass "--all" to
> -exec-continue, but in any way, if a frontend enables non-stop mode, is
> surely has to adjust some of the logic, and changing -exec-continue logic
> does not seem too hard.
>

Exactly.  It's the same amount of work for a frontend writer either way.

If "-exec-continue" (without parameters) resumes all:

The frontend has to add new "resume one thread only button", which 
calls "-exec-continue --thread=x".  The current "resume" button,
already calling "-exec-continue", would resume all threads.

If "-exec-continue" (without parameters) resumes only current thread:

The frontend has to add new "resume all threads" button which 
calls "-exec-continue --thread=all".  The current "resume" button,
already calling "-exec-continue", would resume only the current
thread.

It's the same amount of work for a frontend writer, because
he'd have to write support for one of the new buttons.  In
an hypothetical world, where one could only have access to one
of these buttons, the most useful and general would be the
"resume (current thread)" one.  This means, that if the
frontend writer is lazy, it's better this way :-)

In my simplistic view of the frontend's world, I'd imagine that since
there's a *running notification telling the frontend which threads
resumed, the button actions doesn't have to care much which of the
behaviours (one thread or all-threads) it is triggering.  It's
the notification callback that has to care.

Thanks,
-- 
Pedro Alves