This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI threads behaviour
- From: Pawel Piech <pawel dot piech at windriver dot com>
- To: Marc Khouzam <marc dot khouzam at ericsson dot com>
- Cc: Daniel Jacobowitz <drow at false dot org>, Vladimir Prus <vladimir at codesourcery dot com>, gdb at sources dot redhat dot com
- Date: Mon, 14 Jul 2008 08:55:40 -0700
- Subject: Re: MI threads behaviour
- References: <6D19CA8D71C89C43A057926FE0D4ADAA04291230@ecamlmw720.eamcs.ericsson.se>
Marc Khouzam wrote:
The =thread-selected notification, in this case, should be interpreted to
mean:
(1) User's request that the selected thread be changed, and
(2) Notification that GDB current thread has changed
The (2) trait does not matter if --thread is used, but in this case the
frontend need to use this information to figure if -thread-select should be
sent.
Here, I believe there is a race condition. In the example you give above with
two windows, one window could send a CLI command changing the thread, but
the second window may send an MI command, before receiving the
=thread-selected notification and will act on the wrong thread.
I don't see how we could fix this.
Or maybe I misunderstood your explanation?
Hi Marc,
I seem to remember that we talked about the fact that there is a race
condition and decided that it is unavoidable. Our proposed workaround
was to force the client to wait for the result of each CLI command
before issuing another CLI or MI command. This is certainly
inconvenient, but given the fact that it only applies to CLI commands,
it should not have a performance impact.
Cheers,
Pawel