Re: MI threads behaviour

[Pawel Piech <pawel dot piech at windriver dot com>]

Marc Khouzam wrote:
>   
> > -----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
>
>   
Yes, so the blocking will have to be controlled at a low level based on 
the command type being sent.  What could prove to be more tricky is 
figuring out how to handle the possible flood of =thread-selected events 
for MI commands.  Two simple options would be to either just ignore this 
event while processing MI commands, or two use the --thread option to 
avoid the event all together.
Cheers,
Pawel

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