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

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

On Saturday 14 June 2008 22:14:43 Tom Tromey wrote:
> 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.

What's "these kinds of events"? Are you interested in any change in
inferiour_ptid? Or in any change of user's idea of what thread he
wants to look at? Pedro's a patch to make those different.

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

I think the above question is most important to answer, but we can surely
make the filtering happen in MI code, if Python wants to see all changes.

- Volodya