Re: MI non-stop interface details

[Vladimir Prus <vladimir@codesourcery.com>]

On Sunday 27 April 2008 23:17:02 Pedro Alves wrote:
> A Saturday 26 April 2008 16:39:36, Vladimir Prus wrote:
> > [Marc, Pawel, I CC you since you were involved in the original
> > discussions about MI interface for non-stop mode].
> >
> > Some time ago I've posted a spec for MI interface in non-stop mode.
> > The discussion (and subsequent implementation) revealed a couple of
> > details that I'd like to finally settle.
> >
> > Thread specification
> > --------------------
> >
> > With non-stop mode, we have a possible race condition due to GDB notion
> > of current thread. GDB both uses the current thread to decide on which
> > thread the operation like 'step' should work, and it switches the current
> > thread when a stop event in a thread is detected. As the result, if a
> > frontend emits a command assuming that that current thread is N, and stop
> > even is detected before that command is executed, it will execute in the
> > wrong thread.
> >
> > The current non-stop patches introduce a --thread option to pretty much
> > every MI command, that make MI operate on the specified thread. I think
> > this is the best interface, and will document it as such in the MI docs.
> >
> > At the same time, a suggestion was made to stop GDB to switch the
> > (user-visible) current thread. This will have two advantages:
> >
> >   - CLI users won't see the thread switches
> >   - Some existing frontends are more easily adjusted to this interface.
> >   In particular, Eclipse DSF-GDB does not have a central place where
> >   the --thread option can be conveniently added.
> >
> > Pedro Alves has written a patch that disables the current thread switch, so
> > this approach is in fact possible. I think this leaves us with the
> > following scheme:
> >
> > - In non-stop mode, the current thread is not automatically switched on
> > stops
> > - All MI commands will get the --thread option, as that allows the frontend
> > not to bother with keeping track of the current thread. This option will
> > be recommended in the manual
> 
> If we get rid of the auto thread switching, then GDB's current thread
> will always be the thread the frontend considers current too, because
> it was the frontend that made it the current thread.  What is this
> "keeping track" you mention that would be needed for frontends
> not using --thread?

Suppose that for whatever reason, frontend would like to do anything
in a thread that is not explicitly selected by a user. Then, frontend gets
to switch to that thread, do something, and switch back, and should take
care that no other operation is done while we've temporary switched threads.

> Also, does --thread switch the current thread permanently as if 
> -thread-select was used, or does it only change it for the
> processing of the command?  That is, should GDB revert to the selected
> thread after processing an -exec-* --thread command?

Right now, --thread switches the thread permanently. Which is quite fine
if frontend always adds --thread.

> > - Frontend authors that know what they are doing can ignore the --thread
> > option. (They will have to explicitly emit -thread-select, presumably
> > immediately after seeing the *stopped notification).
> >
> 
> Not immediatelly.  The *stopped notification will once per thread that
> reports a stop.  The frontend would use it to update its internal state 
> representing the thread (change the thread icon to a "-like paused icon
> for instance).  The frontend would send -thread-select when the user
> activelly clicks on another thread icon (or equivalent action).

Of course, a frontend that, in response to *stopped, will do nothing but
marking a thread as stopped, will be fairly unpopular :-) Usually, you
want to show the variables at the stop point, so you'd switch to the stop
thread.

> It doesn't seem much different from switching the internal-to-the-frontend 
> notion of current thread, from which the --thread=$id parameter is built.
> 
> > There are a couple of open questions.
> >
> > 1. Presently, -exec-continue resumes all threads, and the current thread
> > has no effect. I think it's desirable to be able to resume a single thread,
> > and for that, we actually need the --thread option for -exec-continue, to
> > mean that a single thread must be resumed.
> > 2. Presently, -exec-step also resumes all threads. There's an option,
> > "scheduler-locking" that can be used for cause -exec-step to resume only
> > the current thread. It seems to be, that for non-stop mode, resuming all
> > threads is a wrong thing to do, therefore -exec-step, when in non-stop
> > mode, will resume only the thread been stepped. This will be the same
> > no matter if the thread is specified implicitly or explicitly.
> >
> 
> 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.

> If we choose to always ignore the scheduler-locking setting
> in non-stop mode, by making them operate on the current thread
> only, we can still honour '-exec-continue --thread="all"', 
> or '-exec-step --all'.  If people find it desirable, we can
> make "scheduler-locking off" with no --thread specified mean resume
> all threads.  That I tend to agree is wrong in non-stop mode.  I'd
> rather have two buttons on the IDE -- "resume" and "resume all",
> (or two keyboard shortcuts, etc.) then to export the sheduler-locking
> modes to the user interface.

I guess we can redefine the behaviour of -exec-continue in non-stop, or
in MI3, but I worry that two different behaviours will make life too
hard for frontends (and for us)

- Volodya