This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] fix ref counting of inferior_to_inferior_object
- From: Doug Evans <dje at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 25 Sep 2013 12:29:55 -0700
- Subject: Re: [RFA] fix ref counting of inferior_to_inferior_object
- Authentication-results: sourceware.org; auth=none
- References: <yjt2zjrhekva dot fsf at ruffy dot mtv dot corp dot google dot com> <87hadbmfsr dot fsf at fleche dot redhat dot com> <CADPb22RMtbfhhyhv7JRngrH-y8TtOhEyfsXT3twraF42tkMg5w at mail dot gmail dot com> <87ob7giwgd dot fsf at fleche dot redhat 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