This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch:MI] Observer for thread-changed


On Saturday 14 June 2008 23:13:28 Daniel Jacobowitz wrote:
> On Sat, Jun 14, 2008 at 07:09:37PM +0400, Vladimir Prus wrote:
> > I'm afraid you are oversimplifying -- the "the notification is
> > emitted whenever the active thread changes" is very nice, but it's very
> > likely that every frontend author will not realize he has to ignore this
> > notification from -thread-select. So, the documentation should either say
> > that the notification is better ignored, or say that is not emitted. Now, what
> > is better?
> 
> Seems clear to me: it should be in the example output of
> -thread-select, and a reference to there from the description of the
> event.

Which would nicely eliminate any difference in documentation complexity you
originally presented as argument.

> > I'd like this notification to communicate, from GDB to frontend, that GDB
> > has encountered a command that indicates explicit user desire to change
> > the thread he looks at, and that frontend typically should react by making
> > that thread selected in UI. 
> 
> Wouldn't it make sense to use the same notification if the inferior
> stopping causes the selected thread to change, which is how things
> work today in all-stop?

It would. Why GDB changes the selected thread on stop, in the first place? Presumably,
because it thinks that user really want to look at this thread. Then, emitting a
notification suggesting that the frontend shows that thread, makes perfect sense.

> > In other words, I argue for notification to be designed with the view of
> > what frontend is supposed to do with it, not with what internal detail of
> > GDB is been reported.
> 
> This is a good principle, but it's not right either.  Reporting the
> internal state of GDB is bad design, but reporting based on what
> frontends are supposed to do is also bad design: it assumes that you
> can think of everything a frontend might want to do.  We need to
> report logical interface events based on GDB's state.

Oh, we're in too abstract fields now :-) How are you planning to design
logical interface without any consideration what frontend needs, and without
necessary limiting what frontend may be able to do? For all new MI features, 
it's necessary to start with what current frontends need, and build interface
as reasonable generalization of that cases. And, each MI interface,
especially notifications, *must* come with exact documentation of semantics
for frontend. Really, saying that there's current thread and whenever it changes,
frontend is notified, does not actually tell frontend enough to accurately handle
anything.

In light of that, I've started writing a spec about how MI handles threads and
frames, including in non-stop mode. I'm gonna post that soonish, and hopefully
we'll get more concrete discussion.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]