From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1350 invoked by alias); 15 Sep 2014 18:34:41 -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 1334 invoked by uid 89); 15 Sep 2014 18:34:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f176.google.com Received: from mail-vc0-f176.google.com (HELO mail-vc0-f176.google.com) (209.85.220.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 15 Sep 2014 18:34:39 +0000 Received: by mail-vc0-f176.google.com with SMTP id la4so3848453vcb.35 for ; Mon, 15 Sep 2014 11:34:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XiGJX79F2lURvwO091bhvgNwLhAm2aE2hxhbxTMR4Ik=; b=X4PUaNhCnGKEBTR7ZnYTW0iB5Frcet1S6umWs/T6v0XArn51S3HWaAGRRlW2bapCY6 k0efS92tbrF2dZb94gxVzpLgbMoVCaFnUBKGNWz+pv1igjdTPIcOVpE5uiuWJvsFj7ET oAHansUUKqV9QEPcLbNFymoHphiBfc/SE2drS7IuR6+vBJvscqV2tnPEhoRgnWC9JH9g HRcujj7/E9ABRDRhhr0kr7oaWfkQT9EUU+5mJ/TgHax4clCwHThVRL44AWswbVGNXUe+ dIQPA6X0ypmqxhEpKYxzXXPAGdHXpEinpyaF9lHHXkXTh1r3MwszbmcNBX7z7XMFHmXy XyMw== X-Gm-Message-State: ALoCoQliX110xZBe0PH0mLLLjZcW7h4Ht2CiIheNGVDF353oMHmksX9QRQmvzbR4RQrTYmdzeQZo MIME-Version: 1.0 X-Received: by 10.52.139.106 with SMTP id qx10mr20997809vdb.1.1410806077614; Mon, 15 Sep 2014 11:34:37 -0700 (PDT) Received: by 10.52.181.65 with HTTP; Mon, 15 Sep 2014 11:34:37 -0700 (PDT) In-Reply-To: References: <21520.36381.756875.963606@ruffy2.mtv.corp.google.com> <20140911102659.GA17472@blade.nx> <5412DEB5.6020706@redhat.com> <21523.9502.168492.803068@ruffy2.mtv.corp.google.com> <54132B55.9000108@redhat.com> <21523.12189.134570.770432@ruffy2.mtv.corp.google.com> <5413305B.6020402@redhat.com> <21523.13993.986533.615240@ruffy2.mtv.corp.google.com> <54133939.70801@redhat.com> <20140915100736.GA13503@blade.nx> Date: Mon, 15 Sep 2014 18:34:00 -0000 Message-ID: Subject: Re: [PATCH 3/9 v7] Introduce target_{stop,continue}_ptid From: Doug Evans To: Gary Benson Cc: Pedro Alves , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00506.txt.bz2 On Mon, Sep 15, 2014 at 9:00 AM, Doug Evans wrote: > [...] > To advance the discussion, > the async case is the subtle case IMO. Evidently (and I'm just going > by what I see, there may be more data here) someone (*1) looked at the > name "target_stop" and thought it was async (which is probably what Bleah. s/async/synchronous/ > I'd do). The function comment doesn't specify. One could argue it's > sufficient to just fix the function comment, but if we're going to > have a mix of similar functions, some of which are async and some > sync, then IMO we should also make the difference stand out in the > code where it's read. I'd be happy with a convention where all async > functions ended with _async or _no_wait (the latter reads better to > me), but I'm guessing I'd be happy with a different convention as > well. > > FAOD, > there is a bug, but it's not one you specifically need to address. > I pointed it out because it's a data point that contributes to the discussion. > > (*1): I've looked at git log and blame. I'm speaking generically here > because I think this is unlikely to be a one-off kind of issue. Plus I > can well imagine me making a similar mistake too. Plus the bug got > through code review.