Re: [PATCH, doc RFA] Split create-breakpoint! into make-breakpoint, register-breakpoint!

[ludo@gnu.org (Ludovic Courtès)]

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’.