Re: MI3 and async notifications

[Pedro Alves <palves@redhat.com>]

On 6/20/19 4:31 PM, Simon Marchi wrote:
> 
> I am still unsure about emitting events unconditionally.  For example: some frontends want to
> insert "internal" breakpoints, which are breakpoints that are not going to be directly shown to
> users.  They send a -break-insert and decide that the breakpoint which results from this won't be
> propagated to the UI.  But breakpoint async events are propagated to the UI (presumably because
> they originate from the user creating a breakpoint in the CLI).  If GDB now emits an event for
> the -break-insert breakpoint, the frontend can't know right away which future =breakpoint-created
> event it should ignore.  Again, it would need to buffer all =breakpoint-created events until it
> gets the ^done, then let pass through all events except the one that matches the created breakpoint.

In the case of two MI channels, and assuming the issue with MI events not currently
being broadcast to all channels/UIs is fixed, then such a -break-insert would show up
as event in the other MI channel, and that other channel would have no way to know
that that breakpoint is supposed to be internal.

It would seem like this suggests that for such a use case, the breakpoint itself
should carry some "this is an internal breakpoint" property.  Note you can
create internal breakpoints with Python today, but not with MI.

Thanks,
Pedro Alves