Re: MI non-stop mode spec

Pawel Piech wrote:

> Vladimir Prus wrote:
>>>
>>> Thanks for agreeing   Like I
said, I have no idea of the complexity
>>> of such a change.  However, it seems to me that
you should be able to
>>> implement a simple protcol-state-tracking logic
for both CLI and MI
>>> protocols, and simply simulate the --thread
option for commands that
>>> don't supply one.  This way you could have both
the backward compatible
>>> stateful protocol, and have the -thread option
to override it on the
>>> individual commands.
>>>     
>>
>> This might be actually a reasonable thing. On one
thing, not switching
>> the current thread might be good for CLI. On the
other hand, I still believe
>> that --thread is ultimately better solution for MI.
Then, it might be best to
>> make GDB not to switch threads (benefiting CLI and
stateful MI), and
>> also accept --thread for the benefit of newer MI
clients.
>>
>> Now there's the catch that --thread is already
implemented and is rather
>> straightforward, whereas I expect some corner cases
in implementing thread
>> that does not change. I think we'll first get the
non-stop mode working
>> with --thread, and then look into making current
thread not change.
>> (For avoidance of doubt, "then" means
"immediately after" not "someday").
>>   
> 
> I think this would be an excellent compromise.  If
there is any kind of
> a layering between the protocol interpreter and the
underlying
> functions, it shouldn't be too much of a stretch to add
the state
> tracking in the protocol interpreter layer.  

This is one implementation approach -- add current thread in
MI, and switch
GDB's global current thread to MI's current thread when
executing any command.
This is not very hard, but won't help CLI. Another approach
is to do the
same trick for CLI. Yet another approach is to make sure GDB
never changes 
its global thread except internally, when it's guaranteed
not to talk to user.
We'll see which approach is best.

> BTW, for the clients that 
> support both a UI and a command console it would be
even even better if
> CLI and MI maintained their own current thread and
stack frame.  This
> would prevent the two interfaces from interfering with
each other.

Oh, that's interesting idea. But, would it not be confusing
if frontend
shows certain thread and frame as current in UI, whereas
commands in GDB
console operate on some other thread?

- Volodya