From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27181 invoked by alias); 19 Sep 2014 20:47:49 -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 27079 invoked by uid 89); 19 Sep 2014 20:47:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.6 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-f177.google.com Received: from mail-vc0-f177.google.com (HELO mail-vc0-f177.google.com) (209.85.220.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 19 Sep 2014 20:47:47 +0000 Received: by mail-vc0-f177.google.com with SMTP id im17so2412762vcb.36 for ; Fri, 19 Sep 2014 13:47:44 -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=vIyL7JTFifn4KYaxrmR8AdPHfuFmdIfvoHKj5KqAiDk=; b=VbjDJaizlNzuALWxI/wMSqHjmF6jjKkiJENdQ+WeZY1/1mWcIu3MpBViNpjWdQdGAQ Kc8XeY4H3onxTdwPuTb9I2m73A+LL1UVIhTvJSB9HAuk794Pk8Fm64Dx5BMRrqpGR4Os oAPxS9B58pY1xEz227B49b2MHVhpcsO9pUwlSlees30QGITEu1tp12k5Yhvu9QhTO25E n859GgJMhtdoy0KwII+p0CHAdcdD1xPySNYeh8jNSZfjL5mT5BqaYS28q6OxV7clNaYj hIOZwtRlzYYYFq1UVHafQYm8Lp5M59JKKjNXCRIh7s9fDCcaXMr4d0iFF/5dqcvSRRn3 aF/A== X-Gm-Message-State: ALoCoQlllvqE5Fl4gtcoTeAzsvfq160mBfmQP/bDhichNZg7/tnEh6lYTE6LRalGNhueEuGjlX1X MIME-Version: 1.0 X-Received: by 10.52.227.232 with SMTP id sd8mr4850744vdc.4.1411159664657; Fri, 19 Sep 2014 13:47:44 -0700 (PDT) Received: by 10.52.181.65 with HTTP; Fri, 19 Sep 2014 13:47:44 -0700 (PDT) In-Reply-To: <541C50DF.6030105@redhat.com> 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> <54181295.6030302@redhat.com> <541970D8.3080504@redhat.com> <541C50DF.6030105@redhat.com> Date: Fri, 19 Sep 2014 20:47:00 -0000 Message-ID: Subject: Re: [PATCH 3/9 v7] Introduce target_{stop,continue}_ptid From: Doug Evans To: Pedro Alves Cc: Gary Benson , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00641.txt.bz2 On Fri, Sep 19, 2014 at 9:50 AM, Pedro Alves wrote: > On 09/17/2014 07:20 PM, Doug Evans wrote: > >>>> I thought about target_resume. It was an semi-interesting case >>>> that immediately popped into my head at the time. >>>> And then I tried to think how the typical reader would interpret it. >>>> I'm not a typical reader, but I think(!) people would expect it to be >>>> asynchronous in the sense that the inferior is resumed and >>>> control returns to gdb. IOW target_resume doesn't also wait >>>> for the inferior to stop after it has been resumed. >>>> Therefore I see no need to rename it (say to target_resume_no_wait). > > OK. I was reading it like "a convention where all async functions > ended with _async or _no_wait" would be applied throughout. I could > see instead that restricted to cases where we have two variants -- I > guess that's where my understanding was. I did write "... that is otherwise ambiguous". ref: https://sourceware.org/ml/gdb-patches/2014-09/msg00440.html