This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH, doc RFA] Split create-breakpoint! into make-breakpoint, register-breakpoint!
- From: ludo at gnu dot org (Ludovic CourtÃs)
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: xdje42 at gmail dot com, gdb-patches at sourceware dot org
- Date: Wed, 04 Jun 2014 15:47:00 +0200
- Subject: Re: [PATCH, doc RFA] Split create-breakpoint! into make-breakpoint, register-breakpoint!
- Authentication-results: sourceware.org; auth=none
- References: <m3egz5cm1v dot fsf at sspiff dot org> <83fvjl889b dot fsf at gnu dot org> <87y4xdf57p dot fsf at gnu dot org> <83a99t81p7 dot fsf at gnu dot org>
Eli Zaretskii <eliz@gnu.org> skribis:
>> From: ludo@gnu.org (Ludovic CourtÃs)
>> Cc: Doug Evans <xdje42@gmail.com>, gdb-patches@sourceware.org
>> Date: Wed, 04 Jun 2014 10:29:14 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> skribis:
>>
>> >> From: Doug Evans <xdje42@gmail.com>
>> >> Date: Tue, 03 Jun 2014 21:53:48 -0700
>> >>
>> >> In keeping with the splitting of object creation and registration into
>> >> two separate pieces, this does the same for breakpoints.
>> >> "Consistency Is Good".
>> >>
>> >> 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?.
>>
>> I prefer âdelete-breakpoint!â.
>
> 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.
>>
>> 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âs GCâd, that means user code no longer holds a reference to it, so
it cannot register it.
If the user holds a reference to it, then it is not GCâd.
Consider this:
(define b (make-breakpoint ...))
(register-breakpoint! b)
;; ...
(delete-breakpoint! b)
;; ...
(register-breakpoint! b))
This is fine: the breakpoint object wonât be GCâd because itâs
referenced from global variable âbâ.
> 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ât register the above breakpoint because I donât have
;; a reference on it.
(gc) ; the breakpoint above is reclaimed
Ludoâ.