Re: [PATCH] Another annotation for threads

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Nick> But that's exactly what did happen.  Shortly after I submitted a
Nick> patch for the "new-thread" annotation which used the new_thread
Nick> observer, the observer was moved to report the main thread.
Nick> It's pragmatic argument rather than technical one.  I have no
Nick> control over MI development and Vladimir has stated on several
Nick> occasions that MI considerations are paramount.

I'm curious about the long-term view in this area.  I'm perhaps not as
familiar with gdb history as I ought to be to enter this discussion...

It seems to me that the Python work will want notification of all the
same kinds of things that Emacs would, that MI would, and that Insight
would -- regardless of how something happens (an independent event in
the inferior, code run from Python, or user activity on the CLI),
folks will want to be able to write Python that reacts to these
somethings.

Abstractly I would have expected that the gdb core would use observer
notification, and the various state-change consumers (MI, annotations,
Python, etc) would simply register observers as needed.  (At least,
this is what I expected once I found out that events are deprecated.
I already had to add a couple of observers for Python, so this isn't
totally theoretical for me.)

Is this how things "ought" to work?  I mean ideally?
If not, would someone mind summarizing how it really should work?

Tom