Re: [PATCH 2/6] Add annex in an async remote notification.

[Yao Qi <yao at codesourcery dot com>]

On 09/27/2013 02:43 AM, Pedro Alves wrote:
> This mechanism adds a bunch of new code.  I've read the series and the
> descriptions a few times, and I still haven't managed to find where
> the rationale behind these annexes is (or figure it out myself).:-(
>
> _Why_  are they necessary?  What problem do they solve, that simply
> calling these notifications "Trace-status", "Point-modified", and
> later other new notifications "Trace-whatever-else", "Point-whatnot",
> etc. wouldn't solve?  If it's just neat grouping, than it doesn't
> look like worthwhile.
>
> The only thing that comes to mind is ordering -- that is, all
> event with the same base notification handled on a FIFO basis,
> even if they have different annexes.  But that doesn't look like
> to be the reason -- given that the other annex
> hinted -- Point:modified -- belongs to a different notification.

The ordering is the reason we add annex.  As you said, events
with the same basic notification are handled in a FIFO manner.  Events
with Point:created, Point:modified, and Point:deleted should be
processed in a FIFO order, while Trace:status and Trace:foo should be 
processed in FIFO too.  When this series was written,  2013 Jan, hui was 
proposing "target-defined breakpoint", which requires some asnyc 
notifications on breakpoints, so we added annex in V3.

  [PATCH 1/5] Add annex in a async remote notification.
  https://sourceware.org/ml/gdb-patches/2013-01/msg00506.html

Nowadays, we have few notifications (Stop and Trace) and each of them
are not related.  As more notification added, we'll need annex in the
infrastructure, IMO.

A lot of code is added for annex, but the code is more modulized.  It is 
flexible to add a new notification or add a new annex for an
existing notification.

--
Yao (éå)