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

[Tom Tromey <tromey at redhat dot com>]

Daniel> One method I use is to ask myself how complicated the documentation
Daniel> for something will be.  It's much clearer to say "the notification is
Daniel> emitted whenever the active thread changes" than "... unless it
Daniel> changed because of -thread-select".

Vladimir> I'm afraid you are oversimplifying -- the "the notification
Vladimir> is emitted whenever the active thread changes" is very nice,
Vladimir> but it's very likely that every frontend author will not
Vladimir> realize he has to ignore this notification from
Vladimir> -thread-select. So, the documentation should either say that
Vladimir> the notification is better ignored, or say that is not
Vladimir> emitted. Now, what is better?

I think that the Python layer would like to be notified of every
thread change.  That way, it will be possible to write Python
libraries which react to these kinds of events.

If the thread-changed observer is not always notified, is there a way
to do this?  I suppose we could introduce a second observer.

Would it be possible to isolate the "don't print some thread change"
logic into MI-specific code?  Say, by having MI attach to a generic
observer and then filter out the notifications it does not want to
report?

Tom