Re: MI: "^running" issues

[Eli Zaretskii <eliz at gnu dot org>]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Thu, 6 Sep 2007 10:46:21 +0400
> Cc: gdb@sources.redhat.com
> 
> > > What commands are actually meaningful to emit while target are
> > > running
> > 
> > Anything that does not need the target itself, or modifies its state.
> > For example, "help".  
> 
> I hope you'll agree that "help" is not important enough to warrant
> extensive gdb work, so let's drop this example immediately.

Actually, I disagree that it's entirely not important.  I frequently
want to remind myself something about the next command I want to
issue, and doing that while the inferior is running is a good use of
my otherwise idle time.

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

If the target is timing-sensitive, interrupting it is not a good idea,
as it can disrupt the timing and cause all kinds of side effects that
will ruin your debug session.

> > So you are in effect questioning the value of 
> > multithreading.
> 
> Multithreading is not a silver bullet. It should be used when appropriate.
> Are you sure gdb code is thread-safe in any degree? 

GDB code is obviously not thread-safe (we have quite a few global
variables).  But then I didn't suggest to use threads, only that
questioning its limited emulation by the async code is akin to
questioning the value of multithreading.  (I'm sure you know that any
program that uses `select' or `poll' is multithreading in disguise.)

Look, it's quite clear at this point that you've made up your mind
about this issue: you are against the async option.  It's not
necessary to underscore that by attacking every piece of information I
give you.

> > As another data point, the people who wrote the infrastructure for the
> > async execution were two long-time and experienced GDB users and
> > developers, and they obviously thought it was worth coding.
> 
> This is argument by authority, I don't accept it.

You are free to reject it, but then I'm free to object to removing the
async code just because you think it's useless: your authority is no
more important than that of those who suggested and developed the
async code.

> I think at least some design should be present before coding

``Some design'' _was_ presented years ago, when this code was
developed.  You may wish to look in the archives.

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

Thank you so much for mocking my attempt to help you understand the
issue, at your own request.