From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6864 invoked by alias); 25 Sep 2013 18:32:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6854 invoked by uid 89); 25 Sep 2013 18:32:23 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Sep 2013 18:32:23 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8PIWKA6021965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 14:32:20 -0400 Received: from barimba (ovpn-113-63.phx2.redhat.com [10.3.113.63]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8PIWJqf022763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 Sep 2013 14:32:19 -0400 From: Tom Tromey To: Doug Evans Cc: gdb-patches Subject: Re: [RFA] fix ref counting of inferior_to_inferior_object References: <87hadbmfsr.fsf@fleche.redhat.com> Date: Wed, 25 Sep 2013 18:32:00 -0000 In-Reply-To: (Doug Evans's message of "Wed, 25 Sep 2013 11:18:04 -0700") Message-ID: <87ob7giwgd.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-09/txt/msg00902.txt.bz2 >>>>> "Doug" == Doug Evans 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