39/6f2b638adfee2e81796ffd9130a5e1085d5abe

   1 Return-Path: <amdragon@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 3CB2B429E26\r
   6         for <notmuch@notmuchmail.org>; Wed,  7 Sep 2011 19:48:12 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
  13         RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id jUpTNJy453VQ for <notmuch@notmuchmail.org>;\r
  17         Wed,  7 Sep 2011 19:48:11 -0700 (PDT)\r
  18 Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com\r
  19         [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id ECEA2431FB6\r
  22         for <notmuch@notmuchmail.org>; Wed,  7 Sep 2011 19:48:10 -0700 (PDT)\r
  23 Received: by vws12 with SMTP id 12so372024vws.3\r
  24         for <notmuch@notmuchmail.org>; Wed, 07 Sep 2011 19:48:10 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=mime-version:sender:in-reply-to:references:date\r
  27         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;\r
  28         bh=NLmiWyPa1lrMEincKq6BGQYQ/tASmCiuBjTjD3UAJE4=;\r
  29         b=IkOw907YzKzRY7OP/Fmkmz1pjgclKAdhwx88Gb7I/iCallWCsjdkBRZCnYQHvmtonf\r
  30         9roMCxP2Ldsujf1Xz7fRVFrln7gKOW+VeFm8kAXm9BgQZWFlo+lmYEBMpRJ6a8w+5g3e\r
  31         dN/YsSLj0Ucm+YqTep7juy3hwX3kaoxmPOAf8=\r
  32 MIME-Version: 1.0\r
  33 Received: by 10.52.27.140 with SMTP id t12mr152580vdg.156.1315450090320; Wed,\r
  34         07 Sep 2011 19:48:10 -0700 (PDT)\r
  35 Sender: amdragon@gmail.com\r
  36 Received: by 10.220.178.132 with HTTP; Wed, 7 Sep 2011 19:48:10 -0700 (PDT)\r
  37 In-Reply-To: <87aaag3xaf.fsf@gmail.com>\r
  38 References: <8739h1pbaq.fsf@gmail.com> <87pqjprzu2.fsf@gmail.com>\r
  39         <20110829183010.GA2605@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>\r
  40         <87liucyn7i.fsf@gmail.com> <87aaag3xaf.fsf@gmail.com>\r
  41 Date: Wed, 7 Sep 2011 22:48:10 -0400\r
  42 X-Google-Sender-Auth: irs79fZmn6e462fWLmXnNxJFg1w\r
  43 Message-ID:\r
  44  <CAH-f9WsfHUm_D-+wB89Lt9Wt=hjwDyywvJTK-0NwmHRg0TUsxQ@mail.gmail.com>\r
  45 Subject: Re: Memory management practices\r
  46 From: Austin Clements <amdragon@mit.edu>\r
  47 To: Ben Gamari <bgamari.foss@gmail.com>\r
  48 Content-Type: text/plain; charset=ISO-8859-1\r
  49 Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,\r
  50         notmuch <notmuch@notmuchmail.org>, Bart Massey <bart@cs.pdx.edu>\r
  51 X-BeenThere: notmuch@notmuchmail.org\r
  52 X-Mailman-Version: 2.1.13\r
  53 Precedence: list\r
  54 List-Id: "Use and development of the notmuch mail system."\r
  55         <notmuch.notmuchmail.org>\r
  56 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  57         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  58 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  59 List-Post: <mailto:notmuch@notmuchmail.org>\r
  60 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  61 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  62         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  63 X-List-Received-Date: Thu, 08 Sep 2011 02:48:13 -0000\r
  64 \r
  65 On Wed, Sep 7, 2011 at 4:36 PM, Ben Gamari <bgamari.foss@gmail.com> wrote:\r
  66 > On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari <bgamari.foss@gmail.com> wrote:\r
  67 >> [SNIP]\r
  68 >>\r
  69 >> In general, it seems to me that memory management in notmuch bindings is\r
  70 >> a little bit harder than it needs to me due to the decision not to\r
  71 >> talloc_ref parent objects when a new child object is created. This means\r
  72 >> that a bindings author needs to recreate the ownership tree in their\r
  73 >> binding, a task which is fairly easily done (except in the case of\r
  74 >> Haskell due to the weak GC finalization guarantees) but seems quite\r
  75 >> unnecessary. Is there a reason this decision was made? Would a patch be\r
  76 >> accepted adding talloc_ref'ing parents in those functions creating\r
  77 >> children and talloc_frees in *_destroys?\r
  78 >>\r
  79 > Any opinions concerning whether this is an acceptable idea? I wouldn't\r
  80 > mind putting together a patch-set, but I'd rather not waste my time if\r
  81 > the set would ultimately be rejected due to some technical objection I\r
  82 > have yet to think of.\r
  83 >\r
  84 > Cheers,\r
  85 \r
  86 I've been meaning to look in to this in depth.  (I still haven't, but\r
  87 wanted to give you some reply.)\r
  88 \r
  89 In general (though perhaps not always?), libnotmuch uses talloc() to\r
  90 allocate children objects, which already implicitly creates a talloc\r
  91 reference from the parent object to the child object.  You've\r
  92 certainly thought about this harder than I have, but it seems like the\r
  93 bindings should simply create an additional talloc reference and\r
  94 unlink that reference in the GC finalizer, so that the library-created\r
  95 references would maintain the integrity of the data structures, while\r
  96 the binding-created references would maintain their extent.  Hence, I\r
  97 don't see why simultaneous GC would cause problems with talloc, or why\r
  98 the bindings would have to recreate the reference tree.\r
  99 \r
 100 I'm a bit confused by the reference tree you drew.  The references in\r
 101 the underlying libnotmuch objects are the other way around.\r
 102 notmuch_query_t holds a talloc reference to every notmuch_messages_t\r
 103 it produces, not the other way around.  (Though, in reality, these\r
 104 objects are completely independent of each other.  This reference\r
 105 exists purely as a convenience for C programmers to make it easy to\r
 106 clean up all notmuch_messages_t objects when you destroy the\r
 107 notmuch_query_t.  This is probably a poor interface; it may be better\r
 108 to take an explicit talloc context, which could be the query object,\r
 109 or could be something else.  In fact, I would expect this to cause\r
 110 memory *leaks* in bindings if it were not handled carefully, rather\r
 111 than premature GC.)\r