Re: [RFA] fix ref counting of inferior_to_inferior_object

[Doug Evans <dje at google dot com>]

On Wed, Sep 25, 2013 at 11:32 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
>>> The current model is that the Python object mirroring the inferior
>>> clears the inferior->Python mapping when it is finally destroyed.
>>> If the Python code then requests the Python object for that inferior
>>> again, a new object is created.  This is "ok" because the Inferior
>>> object doesn't carry any user state.
>
> Doug> Doesn't the caller always need to know whether s/he is getting a new
> Doug> reference or a borrowed reference?
> Doug> How will s/he keep the reference count correct?
> Doug> [maybe I'm misunderstanding the terms used here]
>
> I believe that in this case, the caller always gets a new reference.
> gdb's "struct inferior" does not own a reference here.

Blech.  Can I ask for a coding convention that prohibits the use of
the word "reference" by itself?  1/2 :-)
Instead, always use "borrowed reference" or "new reference".
Otherwise, I have to dig to make sure the author or user of the code
didn't mistake one for the other (and I'd rather be doing something
else :-)).

> There are different ways to tie the lifetimes of gdb objects and their
> Python wrappers.  One model is that the gdb object owns a reference.
> Another model is that it does not.
>
> Which one we pick depends on a few factors, including whim I suppose.
> If the object has user-settable state, though, then the owning model
> must be preferred.

Not that you disagree or anything, but IWBN to remove whim from the equation.
Consistency Is Good, and all that.

If we're going to store a pointer to the Python object in a gdb
registry, why not have a convention that gdb owns a reference?
[could be missing something of course]

> In the "does not own" model, then the destruction of the last Python
> reference must also clear the link from the gdb object to the Python
> object.  In this case that is done in infpy_dealloc.
>
> It's unclear to me whether we've made the best available choices here.
> There was some discussion on irc about the difficulty of making weak
> references to gdb's wrapper objects.  (This may be just a buglet in the
> class definitions; but it calls into question the "is_valid" model.)
>
> Tom