Re: MI3 and async notifications

[Jan Vrany <jan.vrany@fit.cvut.cz>]

On Mon, 2019-06-17 at 08:56 -0400, Joel Brobecker wrote:
> > I do agree, avoid the extra configurability - but I simply don't know how
> > to work with just async notifications to sync messages. It means that CDT
> > will have to issues the -break-insert, look for the done message and
> > "search" between them to find the =breakpoint-created that matched and
> > separately process any that don't. Please see my earlier message about how
> > to handle race condition between -break-inserts over MI and breaks inserted
> > from CLI. This race condition does not happen during normal operation
> > (where a human is driving everything) but does kick in during many
> > semi-automated flows. Perhaps this isn't a big problem, but to me it seems
> > the logic to match up -break-insert to =breakpoint-created in client side
> > is complex and bug prone.
> 
> The part I don't understand is why it matters to sync the two.
> 
Jonah, I was about to ask the same. I understand that you need to know
which breakpoint has been inserted by given command, but this
if we respond with something like

1-break-insert main
=breakpoint-created,bkpt={number="1",type=...}
1^done,bkpt-number=1

then you just search for breakpoint with that id, no? Given that MI 
guarantees that =breakpoint-created arrives before ^done reply to command.
Am I missing something? 

Also note that this is not only about breakpoints but also about things like
-gdb-set and few others. 

Jan