From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21700 invoked by alias); 25 Sep 2013 18:18:07 -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 21689 invoked by uid 89); 25 Sep 2013 18:18:06 -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 18:18:06 +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 tp5so46047ieb.28 for ; Wed, 25 Sep 2013 11:18:04 -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=RM0qhfZWbNyDBf10w0DEYAIsw3F4qHJ7VxBf7D8uXb8=; b=Ksjshp/zJArTSFMz/LbrcmVBP5H/SXBWQSVi0d6XBaWfeIsFrNVuw+j9LauNppV/kY NYW5hgIWxv1p1zF2MMWwGjOIp/rULWTF8oCJTT2HEtQfdF2Hh9bHzgtDJT4NPyfqn+Lb J1M9Sd6dn5PJD8XKZA592RmwrQV2AYa50xO1kvFTw6slX8cJgLz+W5uLjeg2Mks9OJu+ xvg89TKGobCCe88b5ZqlQgm0nwH4Rcv2q78bbhyDCJu550XRc8BJ0H0+BZHYRz84LkTT xv+7+kCL1RrCVsPC0MQJUevNzTYr02D3L63U0bq3D5/UmtPbxraZFW9UGOTGqpoiBc0f lk7w== X-Gm-Message-State: ALoCoQmDDuriaie6SdqJI5RZqDZ141RzqhAXu55nIrWzPfiurlX2BLdZHrakvr/v9mrHLoJ3wTLhlERyIYTySfWclEEH6VxgJ2Enx09yQOYNKy2it3U2Wx7K8cOojJuVYdGTpH56D6jku15jlkqBbY9L4poCzFslJqPRwF9UAfYyBdYmk2eB3OttOp861XIo++2DqqgXDOqKO4sgIdc4BRkJLXV9FkZE/w== MIME-Version: 1.0 X-Received: by 10.42.82.196 with SMTP id e4mr16848600icl.58.1380133084142; Wed, 25 Sep 2013 11:18:04 -0700 (PDT) Received: by 10.64.31.100 with HTTP; Wed, 25 Sep 2013 11:18:04 -0700 (PDT) In-Reply-To: <87hadbmfsr.fsf@fleche.redhat.com> References: <87hadbmfsr.fsf@fleche.redhat.com> Date: Wed, 25 Sep 2013 18:18: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/msg00901.txt.bz2 On Mon, Sep 23, 2013 at 1:41 PM, Tom Tromey wrote: >>>>>> "Doug" == Doug Evans writes: > > Doug> While adding an inferior attribute to the newobjfile event, > Doug> I noticed inferior_to_inferior_object sometimes returns (AFAICT) > Doug> a new reference and sometimes returns a borrowed reference. > > The current code is maybe weird but I think it isn't incorrect. That > said it is fine to change it as well. > > 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. Doesn't the caller always need to know whether s/he is getting a new reference or a borrowed reference? How will s/he keep the reference count correct? [maybe I'm misunderstanding the terms used here]