Re: MI: "^running" issues

[Vladimir Prus <ghost at cs dot msu dot su>]

On Thursday 06 September 2007 22:48:43 Eli Zaretskii wrote:
> > 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.

OK.

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

It appears to me that the time to interrupt the target, print output
and resume is roughly equal to the time it takes to a hit of breakpoint
with commands. You'd need a minimal degree of asynchronous operation to
support that.

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

I actually thought you mean multi-threading, literally. Without MT,
you can basically run one command on gdb side, together with one
command running inferior. With MT, it would be possible to run several
long running commands on gdb side, which I thought you were talking about.

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

Does it work now? Are there tests for it? And basically, I don't
care much about existing code. What I'm concerned is that I have
a real bug, where "^running" is not output where it should be.
The code related to that bug has something to do with async mode,
but it's pretty unclear why it should be, and how would I test
that my fixes don't break that async mode.
 
> > 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.

I'm sorry that you feel that way. Unfortunately, I continue to believe
that in order to talk about async mode, we need some design, readily 
accessible to all interested parties. I failed to find such design
in the archives; and from this discussion it appears that the value
of async mode lies in different things for different people.

- Volodya