Re: MI3 and async notifications

[Simon Marchi <simark@simark.ca>]

On 2019-06-10 5:19 p.m., Jan Vrany wrote:
> Hello,
> 
> as an user og GDB/MI (and frontent developer), I'd like to 
> open a discussion about one aspect of MI that I'd like to change
> in MI3 before it is released into the wild. 

Hi Jan and others,

Thanks, nice to see some action on improving MI.

I have just read the thread, and I have a few questions about where
this is going.

> Currently, quite a few commands suppress async notifications when
> a command is issued through MI. For example, when a breakpoint is 
> added using -break-insert then =breakpoint-created is not emitted.
> 
> At least in my case, this behavior complicates client design because
> now the client has to care for new breakpoints on multiple places:
> (i)  listen to breakpoint created events to handle cases where breakpoint
>      is added via CLI. 
> (ii) do similar processing whenever MI returns ^done for previously 
>      issued -break-insert command.
>  
> This leads to a complex logic, especially in cases where frontend has
> some scripting support (so execution of MI commands is not completely
> under frontend developer's control).
>
> Emitting notifications unconditionally would simplify things a lot 
> - again at least in my case.

The idea of the current behavior is that you shouldn't be asynchronously notified
of the result of your own command.  As was illustrated in this thread, it would be
difficult to determine whether a =breakpoint-created async notification is the result
of the pending -break-insert, or it just happens that the user has created a breakpoint
on the CLI at the same time.  So to remove this ambiguity, we don't send the notification.

I am skeptical about the complex logic you are talking about to handle both
=breakpoint-created notifications and responses to the -break-insert.  Both contain pretty
much the same information.  So rather than adding an option in GDB for emitting async
notifications unconditionally, can't you just process both using the same function?  That
doesn't really complicated, but maybe I am misunderstanding your problem, in which case
please expand.

It would be useful to have a very concrete use case where you could point out "see here,
I am missing some info and a notification would be useful".  It could very well be that
some notifications are just missing.  For example I would argue we are missing notifications
if using two MI clients (through the new-ui command, although I don't remember if that's
"officially" supported).  If one of the MI client inserts a breakpoint with -break-insert,
the other one is not notified.  I would consider that a bug that the second client doesn't
get a =breakpoint-created.

Also, I am a bit worried by a proposal in the thread, which would be to remove information
from the -break-insert ^done response, arguing that the async notification would have already
been emitted.  It is clear and unambiguous how to map a response to a request, but it would not
be obvious to map an async notification to a request.  So it appears to me as a regression in
functionality.

Simon