From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3371 invoked by alias); 25 Sep 2013 19:29:58 -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 3360 invoked by uid 89); 25 Sep 2013 19:29:58 -0000 Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com) (209.85.223.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 25 Sep 2013 19:29:58 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f169.google.com Received: by mail-ie0-f169.google.com with SMTP id tp5so162389ieb.0 for ; Wed, 25 Sep 2013 12:29:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q/pFsLU15KfhTPQNaXNz4GTiu8i9PrkkbLDRmgdKdDg=; b=T9bSN2gWOFGqLM+srHGnb+xk7QSJiJJADgtZL897MJ7fideBEbqNEgtH4A1QAbBY5m jHdry1KEwOvGcnbnDascPL78yrFumkJ5s4InulE7ZpqccB10PKUmZbBJGPfwNG4WjAYe 11oWNR67XIrFRHVp9UxYIrjhNRcg4hEk+ZaUmqMhNXaf05RCZ7UJFmpI5+2GsK7VXFgU AtHCYXDwUVo/aeQRcB2l7IiXhLghjhrK9E9RT/XuuHCKTdQ8fhvn/v6oau6lW65lo19r jD8c9fKwqNMiyNOLLZXrNN/jveRj+Qyoig4SPf5RwKKAvPnhGlKEOqaz2fz3OKaKi65K pXRg== X-Gm-Message-State: ALoCoQlVRwLQIDdv68zIQAEomQ8UsdTU2am5l124USbEXCOLz+4suPmuo95DQQxqQww56kfj0Kwzc5YDCfpCbbzdKOHRrqf2to6NS+r+DK0sOt+w7Pq9rx17MjsRYqRqWpP84BnJAYne2Nqy21kcYKemLDC/uNfAiCtAY6qw5F0ewh/XHaTNGnK4VSS7NDJwaY7eQy+yrhqSzLnaMfXffo+YF07EQWPKdg== MIME-Version: 1.0 X-Received: by 10.42.64.74 with SMTP id f10mr2954219ici.86.1380137395534; Wed, 25 Sep 2013 12:29:55 -0700 (PDT) Received: by 10.64.31.100 with HTTP; Wed, 25 Sep 2013 12:29:55 -0700 (PDT) In-Reply-To: <87ob7giwgd.fsf@fleche.redhat.com> References: <87hadbmfsr.fsf@fleche.redhat.com> <87ob7giwgd.fsf@fleche.redhat.com> Date: Wed, 25 Sep 2013 19:29:00 -0000 Message-ID: Subject: Re: [RFA] fix ref counting of inferior_to_inferior_object From: Doug Evans To: Tom Tromey Cc: gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00904.txt.bz2 On Wed, Sep 25, 2013 at 11:32 AM, Tom Tromey wrote: >>>>>> "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. 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