RE: MI threads behaviour

Marc Khouzam
2008-07-14T16:04:03Z

> -----Original Message-----
> From: Pawel Piech [mailto:pawel.piech@windriver.com]
> Sent: Monday, July 14, 2008 11:56 AM
> To: Marc Khouzam
> Cc: Daniel Jacobowitz; Vladimir Prus; gdb@sources.redhat.com
> Subject: Re: MI threads behaviour
>
>
> 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.

With the example of two windows, can we block an MI command on window 2
waiting for the CLI command to finish on window 1?
I guess I didn't fully understand the example.
Either way, I'm sure this solution if fine.

Thanks

> This is certainly
> inconvenient, but given the fact that it only applies to CLI
> commands,
> it should not have a performance impact.
>
> Cheers,
> Pawel
>