Re: MI3 and async notifications

[Jonah Graham <jonah@kichwacoders.com>]

On Mon, 17 Jun 2019 at 08:14, Joel Brobecker <brobecker@adacore.com> wrote:

> > > It seems like a good idea to me.  I wonder if it makes sense to go even
> > > further and say there will only be async notifications for things like
> > > this.
> >
> > Yes, I thought the same initially. But then what about other existing MI
> > consumers?
>


> In my opinion, while I think upward compatibility is very important,
> it is also important to avoid having too many configurability options.
> Otherwise, we end up with a large number of options and the testing
> matrix, if we want to verify that they work well together, quickly
> explodes.
>
> In this case, because we have MI versions, and because the notification
> shouldn't be different from the data of the "^done" message, I think
> the incompatibility would be acceptable -- assuming existing parsers
> don't come back to say that it actually is a large effort for them
> to adapt.
>
>
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.