MI non-stop interface details

[Vladimir Prus <vladimir@codesourcery.com>]

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

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.

Inferior function calls
-----------------------

We already have the *stopped async event, and I have a patch to introduce the
*running async event. Those are not emitted when doing inferiour function calls,
since doing so may cause a frontend to infinitely refresh its state. I propose
the following mechanism to enable those notifications for frontends that
are sufficiently robust:

1. Declare that MI might have some features that are not enabled by default.
2. Introduce new command -enable-feature, which takes a name of feature and enables
it. 
3. Make up a name of a feature, say inferior_call_notifications, and add that
feature to the output of -list-features.
4. Make '-enable-feature inferior_call_notification' enable *running and *stopped
for inferiour function calls.

Any comments?

- Volodya