MI threads behaviour

[Marc Khouzam]

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