Re: [RFC 0/7 V3]A general notification in GDB RSP

[Yao Qi <yao at codesourcery dot com>]

On 11/20/2012 02:46 AM, Pedro Alves wrote:
> sorry for the delay.  I've I've been staring at this series for a while,
> and I'll have comments to make in the individual patches.  But one general
> concern came to me.  There doesn't seem to be any order guarantee
> between the different notifications.  IOW, considering the trace-stopped
> notification you proposed in a follow-up series. if a given thread
> is tracing/running, and it stops tracing, and then hits another event
> that should be reported too (e.g., a stop event - breakpoint/signal/etc.),
> GDB could see the events as either:
>
>   #1 - trace stopped
>   #2 - thread stopped
>
> or:
>
>   #a - thread stopped
>   #b - trace stopped
>
> Is that so?  I was trying to convince myself that is okay both
> in this particular case and in general, but I'm not really sure.
> It sounds like one of those things that might byte back.  I'd like to
> hear your (and others', of course) thoughts on this.

Right, we can't guarantee the order of multiple notifications.  Once GDB 
gets the first notification N, it will ask remote to give it the rest of 
queued notifications N one by one.  It simplifies RSP and logic a lot, 
but it breaks the order of notifications of different types (while the 
order of notifications of the same type is still kept).  We call it 
'partial order'.

In general, the notification consumers shouldn't reply on the order of 
notifications, and notification should be independent of each other.  In 
my brain, there are three notification use cases,
  1) trace stop notification
  2) stub verbose output notification (stub gives some verbose info 
while doing some slow operations, such as jtag operations)
  3) flash writing notification (report the progress).
None of them is sensitive on the order (with other notifications and stop).

When adding a new notification M, M should be independent of all 
existing notifications.  Otherwise, we have to extend existing 
notification instead of adding a new one.  For example, supposing that 
we have a notification trace-stopped, and we want to add a new 
notification trace-started, the order of them should be kept.  In this 
case, we have to extend trace-stopped to trace-changed notification to 
handle both.

IMO, supporting 'total order' notification is relatively complicated, 
and no strong request is found so far.
--
Yao (éå)