Re: MI: "^running" issues

[Vladimir Prus <ghost@cs.msu.su>]

Bob Rossi wrote:

> On Thu, Sep 06, 2007 at 10:46:21AM +0400, Vladimir Prus wrote:
>> On Thursday 06 September 2007 07:19:11 Eli Zaretskii wrote:
>> > > From:  Vladimir Prus <ghost@cs.msu.su>
>> > > Date:  Wed, 05 Sep 2007 22:41:38 +0400
>> > A less trivial example is "info break" (to see
>> > what breakpoints were already hit during execution up to now, in case
>> > your "commands" for the breakpoints continue the target).
>> 
>> Technically speaking, you don't need async for that -- you can interrupt
>> the target, provide output, and then go on. Making this async will maybe
>> cut some fraction of section from the run time, why do we care?
> 
> This isn't necessarily true. It is not guarenteed that you will be able
> to interupt the target. I'm pretty sure this won't always work with
> cygwin.

Given that Visual Studio can interrupt running process, what you describe
above appears to be cygwin problem, not inherent problem with windows. 
Therefore, it probably should be fixed in cygwin. There's no need to
change gdb.

>> > Note that I'm not actually saying these commands will work
>> > asynchronously in the current GDB, as the implementation of async
>> > execution was never finished, AFAIK.
>> > 
>> > > and are those commands of big enough value to user to warrant
>> > > extensive coding?
> 
> One example of a command that would be really useful would be
> -exec-interupt. I've discussed this extensively in the past. Sending a
> ^c to the inferior is not the perfect way to stop the inferior from
> running.  That's because typically a front end will put the inferior on
> a tty to separate the output of the inferior from the output of gdb/mi.
> 
> As soon as this is done, it becomes unclear if the ^c should be sent to
> the gdb/mi tty or the inferior stdin tty. Again, this is especially true
> on windows.

Sendind ^C to gdb/mi tty appears to work fine (with program on separate tty).
What's the problem?
 
>> The way it stands now is more like "let's develop async mode, and then
>> see what commands we can run in async mode, and then see what benefit
>> that will have".
> 
> Yeah, in general, I think this is how the MI stuff is developed though.
> There doesn't seem to be anyone with a clear vision dedicated to gdb/mi.
> It's unfortunate. I mean, each front end developer of gdb/mi eventually
> becomes a gdb/mi developer. It's pretty sad.

It is. But it does not mean future MI development should be in similar vein.

- Volodya