[patch:MI] Observer for thread-changed
Vladimir Prus
ghost@cs.msu.su
Tue Jun 10 08:26:00 GMT 2008
On Tuesday 10 June 2008 06:03:46 Nick Roberts wrote:
> > It all amounts to:
> >
> > - should there be an MI async event on -thread-select if the
> > reply already carries that information?
>
> But the CLI command "thread" doesn't. I think MI should try to reflect the
> state of GDB and the inferior. It shouldn't really matter what commands were
> used to put it in that state.
We had this discussion in context of breakpoint notifications already, but I
think the thread notification makes those issues easier to discuss.
What is the purpose of the thread change notification? I think the purpose is
to enable the frontend to notice when the thread change, unexpectedly. For
example, due to "thread" CLI command or user-defined command that switches
threads, or due to an otherwise magical way. The frontend, most likely, should
react by marking the thread reported as selected by GDB also selected in GUI.
The question, then, if whether -thread-select should output this notification?
Suppose a frontend uses -thread-select to get some data in some thread without
making it selected. Then, if a notification is emitted, the frontend has to
take special care not to mark the thread as selected in GUI.
As an aside, this is similar to notifications/signals in GUI libraries -- for
example, line edit control often has 'text changed' signal. If this signal is
emitted even when the text is changed programmatically, the application
often has to specially prevent signals emitted as result of programmatic change
to be handled as if it was the user input.
So, I think that -thread-select *should not* emit thread-changed notification.
With the original version of your patch, it would be a one-line change, it's
probably a bit harder with the last version.
- Volodya
More information about the Gdb-patches
mailing list