From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 553 invoked by alias); 27 Sep 2013 01:44:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 539 invoked by uid 89); 27 Sep 2013 01:44:54 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Sep 2013 01:44:54 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=4.2 required=5.0 tests=AWL,BAYES_00,GARBLED_BODY,RDNS_NONE,SPAM_SUBJECT,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1VPN6v-0003or-94 from Yao_Qi@mentor.com ; Thu, 26 Sep 2013 18:44:49 -0700 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Sep 2013 18:44:48 -0700 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.2.247.3; Thu, 26 Sep 2013 18:44:48 -0700 Message-ID: <5244E2F6.6050306@codesourcery.com> Date: Fri, 27 Sep 2013 01:44:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [PATCH 2/6] Add annex in an async remote notification. References: <1376877311-4135-1-git-send-email-yao@codesourcery.com> <1376877311-4135-3-git-send-email-yao@codesourcery.com> <52448041.3070703@redhat.com> In-Reply-To: <52448041.3070703@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00946.txt.bz2 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 (齐尧)