From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 890 invoked by alias); 4 Jun 2014 13:47:05 -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 879 invoked by uid 89); 4 Jun 2014 13:47:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: hera.aquilenet.fr Received: from hera.aquilenet.fr (HELO hera.aquilenet.fr) (141.255.128.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jun 2014 13:47:03 +0000 Received: from localhost (localhost [127.0.0.1]) by hera.aquilenet.fr (Postfix) with ESMTP id 74F652BC2; Wed, 4 Jun 2014 15:47:01 +0200 (CEST) Received: from hera.aquilenet.fr ([127.0.0.1]) by localhost (hera.aquilenet.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXMSgaSHwGbC; Wed, 4 Jun 2014 15:47:01 +0200 (CEST) Received: from pluto (reverse-83.fdn.fr [80.67.176.83]) by hera.aquilenet.fr (Postfix) with ESMTPSA id EFD3C6E5; Wed, 4 Jun 2014 15:47:00 +0200 (CEST) From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Eli Zaretskii Cc: xdje42@gmail.com, gdb-patches@sourceware.org Subject: Re: [PATCH, doc RFA] Split create-breakpoint! into make-breakpoint, register-breakpoint! References: <83fvjl889b.fsf@gnu.org> <87y4xdf57p.fsf@gnu.org> <83a99t81p7.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 16 Prairial an 222 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Wed, 04 Jun 2014 13:47:00 -0000 In-Reply-To: <83a99t81p7.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 04 Jun 2014 12:27:00 +0300") Message-ID: <878upceqi3.fsf@gnu.org> User-Agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-06/txt/msg00164.txt.bz2 Eli Zaretskii skribis: >> From: ludo@gnu.org (Ludovic Court=C3=A8s) >> Cc: Doug Evans , gdb-patches@sourceware.org >> Date: Wed, 04 Jun 2014 10:29:14 +0200 >>=20 >> Eli Zaretskii skribis: >>=20 >> >> From: Doug Evans >> >> Date: Tue, 03 Jun 2014 21:53:48 -0700 >> >>=20 >> >> In keeping with the splitting of object creation and registration into >> >> two separate pieces, this does the same for breakpoints. >> >> "Consistency Is Good". >> >>=20 >> >> There hasn't been an FSF release of gdb+guile yet so I think it's ok >> >> to remove create-breakpoint! here. >> > >> > OK for the documentation part, but is delete-breakpoint a better name >> > than breakpoint-delete?. >>=20 >> I prefer =E2=80=98delete-breakpoint!=E2=80=99. > > Fine with me. > > (Btw, what exactly is the principle behind the usage of the trailing > exclam?) It denotes procedures that mutate one of their arguments or some global state (here it mutates an implicit list of registered breakpoints.) >> > A question: how does one discard breakpoint objects so that they no >> > longer exist? It seems that breakpoint-delete! only "deregisters" the >> > breakpoint, but there's no way to undo the effect of the >> > create-breakpoint procedure. >>=20 >> They just get garbage collected eventually. > > That's what I suspected. But then we cannot say in the manual that a > breakpoint deleted by breakpoint-delete! can later be re-registered, > can we? Because if the object was GCed, we cannot register it, can > we? If it=E2=80=99s GC=E2=80=99d, that means user code no longer holds a refere= nce to it, so it cannot register it. If the user holds a reference to it, then it is not GC=E2=80=99d. Consider this: (define b (make-breakpoint ...)) (register-breakpoint! b) ;; ... (delete-breakpoint! b) ;; ... (register-breakpoint! b)) This is fine: the breakpoint object won=E2=80=99t be GC=E2=80=99d because i= t=E2=80=99s referenced from global variable =E2=80=98b=E2=80=99. > Actually, there's a more serious problem here: what if the object > created by create-breakpoint is GCed _before_ we register it the first > time? GC can strike whenever it feels like, so we _must_ explain that > a Guile variable that holds the breakpoint object should never go out > of scope before it is used to register the breakpoint. Am I missing > something? Yes, if it goes out of scope, then by definitions it means that it cannot be registered because we no longer have a handle on it. For instance: (make-breakpoint ...) ; ignore return value ;; Here I can=E2=80=99t register the above breakpoint because I don=E2=80= =99t have ;; a reference on it. (gc) ; the breakpoint above is reclaimed Ludo=E2=80=99.