Re: MI non-stop interface details

[Pedro Alves <pedro@codesourcery.com>]

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?

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?

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

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.

-- 
Pedro Alves