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: Tom Tromey <tromey at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 25 Sep 2013 12:32:18 -0600
- 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>
>>>>> "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.
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.
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