From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23876 invoked by alias); 12 Sep 2014 17:10:22 -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 23864 invoked by uid 89); 12 Sep 2014 17:10:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.5 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-pa0-f73.google.com Received: from mail-pa0-f73.google.com (HELO mail-pa0-f73.google.com) (209.85.220.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 12 Sep 2014 17:10:20 +0000 Received: by mail-pa0-f73.google.com with SMTP id kx10so211863pab.0 for ; Fri, 12 Sep 2014 10:10:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=pQf1bNZSvBuwZRHbYTe/3aDDpbS7wN5b1Y2fuQHfGoU=; b=IT82eDSq5/eqLqjBlBbaXwh8Tlyt4gTnpXUHjAOyllKzRJCcLq/Nrw8rImtrJsYGqA fnNnYpisZYydlbvHAsDz5KgDyhzTpgUjTBb6HTS9LjzFDJBy5y2lP4i6NbX8s6/Ugnk9 23DnZ3mD0YMFVjFLkk0m9cqZ82ZuBAAr4lZ4G2W59FKoam7wbKH9mIhPtKeSe5/7ce53 ontiLiHHybCNC0ke9PT16A6c3A9wp/cgoWrwuEbp+uFfnVgiKin/DtDEx2/+hHMJBtNF Lw/MpH2IsoREZoW0DPFkBbp8DW1yZIqaZD5BJg36cEdmqOPWxqzhSt6BGPGkbFrt9APt +lAQ== X-Gm-Message-State: ALoCoQkIZgEzmIUPuN3HB6wfYGiHNRgElIwSb1CGgdgqVL7rD5NXVg1xMHvgI9LcmgW2indZYpxcim0PwHJrOcRkU9LdKaACUf3oNgHtSG4LsaUQHVoFcbSJX5NKao/uCSE9my908CNNXH6C81pm06Q7/sL5XMq3G3ANZ7UtJ6fR5klVe2Cm7Q8= X-Received: by 10.66.177.108 with SMTP id cp12mr5162070pac.14.1410541818636; Fri, 12 Sep 2014 10:10:18 -0700 (PDT) Received: from corpmail-nozzle1-1.hot.corp.google.com ([100.108.1.104]) by gmr-mx.google.com with ESMTPS id e24si207660yhe.3.2014.09.12.10.10.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Sep 2014 10:10:18 -0700 (PDT) Received: from ruffy2.mtv.corp.google.com ([172.17.128.107]) by corpmail-nozzle1-1.hot.corp.google.com with ESMTP id rwtx0CqN.1; Fri, 12 Sep 2014 10:10:18 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21523.10487.99151.259254@ruffy2.mtv.corp.google.com> Date: Fri, 12 Sep 2014 17:10:00 -0000 To: Pedro Alves Cc: Gary Benson , gdb-patches@sourceware.org Subject: Re: [PATCH 3/9 v7] Introduce target_{stop,continue}_ptid In-Reply-To: <5412E03C.1070402@redhat.com> References: <1409320299-6812-1-git-send-email-gbenson@redhat.com> <1409320299-6812-4-git-send-email-gbenson@redhat.com> <5412E03C.1070402@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00440.txt.bz2 Pedro Alves writes: > On 08/29/2014 02:51 PM, Gary Benson wrote: > > > +/* See target/target.h. */ > > + > > +void > > +target_stop_ptid (ptid_t ptid) > > +{ > > + struct target_waitstatus status; > > + int was_non_stop = non_stop; > > + > > + non_stop = 1; > > + target_stop (ptid); > > + > > + memset (&status, 0, sizeof (status)); > > + target_wait (ptid, &status, 0); > > + > > + non_stop = was_non_stop; > > +} > > One thing that was bugging me was that given that the names > of target_stop and target_stop_ptid are so similar and that > they have the same signature is ripe for confusion. > > I just now noticed the elephant in the room -- target_stop is > asynchronous, doesn't wait for a stop, while and target_stop_ptid > is synchronous. Would you mind renaming this to target_stop_wait > or some such? And then add an explicit "and wait for it to stop" > or some such to the function's description. target_stop_and_wait would be a significantly more readable to me. ["stop_wait" makes me pause too long to figure out what was meant] Or if a plain reading of "target_stop" implies waiting, then rename target_stop to target_stop_no_wait or target_stop_async. and use "target_stop" for "target stop and wait". Do we want a convention for marking async vs sync routines? e.g. append every async routine that is otherwise ambiguous with _async? Or if gdb is becoming generally async, turn it around and append _sync to every sync routine that is otherwise ambiguous. [Or even allow both in certain instances.] That way we'd no longer have to have individual discussions whenever the topic comes up.