Re: MI non-stop interface details

[Vladimir Prus <vladimir at codesourcery dot com>]

On Tuesday 29 April 2008 22:56:15 Marc Khouzam wrote:
> 
> > > > Can we make -exec-continue/-exec-step/-exec-next consistent, by
> > > > making the case of not passing a --thread parameter semantics
> > > > match?  Given the same arguments, if one resumes just one thread,
> > > > the others should too, IMHO.
> > >
> > > Too late. -exec-continue resumes everything. -exec-step, from user
> > > standpoint, resumes one -- most users don't even know that step
> > > can resume all threads.
> > >
> > 
> > Oh, I'm talking non-stop mode.  It's not too late for that.
> > 
> > I played a bit with eclipse/java debugging (which implements non-stop),
> > and noticed it only resumes one thread when one clicks the
> > equivalent of "continue".  I have used eclipse/java heavilly in the
> > past, and I never found that unintuitive.  I remember
> > looking for a "continue all" button and not finding one, but normally
> > I didn't even thing about it.  Resuming one thread was just fine.
> > 
> > (I keep thinking that in non-stop mode, the exec commands without
> > --thread are equivalent to the CLI commands in non-stop mode.
> > 
> > I keep forgetting to pass --thread to continue& and end up
> > resuming more than I wanted.)
> 
> I'm also leaning towards this: -exec-continue only continuing
> the current thread, a la java.
> Although, also having a 'continue all' may prove useful.

Again -- exec-continue resuming just one thread will be a change in behaviour.
We can take two approaches:

1. The MI interface we've discussed for non-stop is essentially MI3 (and will
be used both in all-stop and non-stop mode). We're in position to change anything
we like, and are not bound by backward compatibility, or anything.

2. The MI interface for non-stop is MI2 + minimal set of changes. I think that
Pawel's opposition to the --thread idea indicates that he prefers this approach.
Then, we rather not change the behaviour of existing commands.

There are not many high-level warts in MI2/non-stop/async, so I'm willing
to go with (2).

- Volodya