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

[Bob Rossi <bob_rossi at cox dot net>]

On Sat, Jun 14, 2008 at 12:14:43PM -0600, 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.

I can tell you this. The annotate-1 interface used to send out things
like breakpoints-changed whenever something happened that triggered a
breakpoint change. This data would come out so fast, it would effect the
performance of the front end from getting meaningful data.

I'm just giving a little advice, make sure that gdb doesn't auto send
out information if the inferior can manipulate itself in such a way that
it would effectively flood the communication between gdb and the front
end.

Can thread changes happen often? how often? how will this effect the
communication load?

Bob Rossi