c5/79b42c4abea4aa4638d85c884743aecd14db13

   1 Return-Path: <amdragon@mit.edu>\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 54E73429E21\r
   6         for <notmuch@notmuchmail.org>; Sun, 11 Sep 2011 19:15:54 -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.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id TQgoo-7b5PFo for <notmuch@notmuchmail.org>;\r
  16         Sun, 11 Sep 2011 19:15:53 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU\r
  18         [18.9.25.13])\r
  19         by olra.theworths.org (Postfix) with ESMTP id C6D35431FB6\r
  20         for <notmuch@notmuchmail.org>; Sun, 11 Sep 2011 19:15:53 -0700 (PDT)\r
  21 X-AuditID: 1209190d-b7be0ae000000a16-60-4e6d6a80d298\r
  22 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
  23         by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id B8.33.02582.08A6D6E4; Sun, 11 Sep 2011 22:12:16 -0400 (EDT)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p8C2Fp5c025263; \r
  27         Sun, 11 Sep 2011 22:15:51 -0400\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p8C2Fnhw020305\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Sun, 11 Sep 2011 22:15:50 -0400 (EDT)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.72)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1R2w6E-0000Vj-Vc; Sun, 11 Sep 2011 22:18:18 -0400\r
  37 Date: Sun, 11 Sep 2011 22:18:18 -0400\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Ben Gamari <bgamari.foss@gmail.com>\r
  40 Subject: Re: Memory management practices\r
  41 Message-ID: <20110912021818.GD23603@mit.edu>\r
  42 References: <20110829183010.GA2605@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>\r
  43         <87liucyn7i.fsf@gmail.com> <87aaag3xaf.fsf@gmail.com>\r
  44         <CAH-f9WsfHUm_D-+wB89Lt9Wt=hjwDyywvJTK-0NwmHRg0TUsxQ@mail.gmail.com>\r
  45         <CAH-f9WveBfvmv2jOF+C81OeeQJt06g6U0q3J_idHrs60DLw7+g@mail.gmail.com>\r
  46         <87zkiff8in.fsf@SSpaeth.de> <20110908151557.GM5688@mit.edu>\r
  47         <8762l22hgk.fsf@SSpaeth.de> <20110909175328.GV5688@mit.edu>\r
  48         <87d3f64ups.fsf@gmail.com>\r
  49 MIME-Version: 1.0\r
  50 Content-Type: text/plain; charset=us-ascii\r
  51 Content-Disposition: inline\r
  52 In-Reply-To: <87d3f64ups.fsf@gmail.com>\r
  53 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  54 X-Brightmail-Tracker:\r
  55  H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsUixG6notuQletn0LBT2aLx7z0mi5lP9jJb\r
  56         LF8lZXHz5xw2i+s3ZzJbzJozj9GBzeP16mmsHrs3P2Dx2DnrLrvH0wmT2T2erbrF7LH4y1KW\r
  57         ALYoLpuU1JzMstQifbsErowlnxrYCw4IVhxbPYWpgXETXxcjJ4eEgInEtB9v2CFsMYkL99az\r
  58         gdhCAvsYJe6ctuti5AKyNzBKzFn5hRXCOckksXPNL0YIZwmjxNxve5lBWlgEVCUutx8Gs9kE\r
  59         NCS27V/OCGKLCKhL7H07jw2kgVngJqPE5hP9YEXCQEUzH3SD7eMV0JF4N3cT1O61zBJzJpVB\r
  60         xAUlTs58wgJiMwtoSdz495Kpi5EDyJaWWP6PAyTMCTT/17J2sBJRARWJa/vb2SYwCs1C0j0L\r
  61         SfcshO4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdI30cjNL9FJTSjcxguKEU5J3B+O7g0qH\r
  62         GAU4GJV4eFfeyPETYk0sK67MPcQoycGkJMpbCowyIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8\r
  63         DXpA5bwpiZVVqUX5MClpDhYlcd7CHQ5+QgLpiSWp2ampBalFMFkZDg4lCd6tIEMFi1LTUyvS\r
  64         MnNKENJMHJwgw3mAhm8CqeEtLkjMLc5Mh8ifYtTlOL/2+nFGIZa8/LxUKXHeFpAiAZCijNI8\r
  65         uDmw9PaKURzoLWHejSBVPMDUCDfpFdASJqAlAdszQZaUJCKkpBoYy6b9fDFP9PV0/f++kb4P\r
  66         a2Yuao+1eXdF7FXH90WGT0M5Nt36NaU/5mJ7gLBwASvbs0Ces7f3zXAOMborWvSgQr/t2IX0\r
  67         k0eS8zcynLNU4Up7aOL8orLBrGKKf+Hl5Gmiiqsv1eYXndiY57bfkMFlamS5+pfUOSLvdDmf\r
  68         HZyY6cX3cMMpqVvySizFGYmGWsxFxYkA8KxBBUoDAAA=\r
  69 Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,\r
  70         Bart Massey <bart@cs.pdx.edu>, notmuch <notmuch@notmuchmail.org>\r
  71 X-BeenThere: notmuch@notmuchmail.org\r
  72 X-Mailman-Version: 2.1.13\r
  73 Precedence: list\r
  74 List-Id: "Use and development of the notmuch mail system."\r
  75         <notmuch.notmuchmail.org>\r
  76 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  77         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  78 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  79 List-Post: <mailto:notmuch@notmuchmail.org>\r
  80 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  81 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  82         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  83 X-List-Received-Date: Mon, 12 Sep 2011 02:15:54 -0000\r
  84 \r
  85 Quoth Ben Gamari on Sep 11 at  5:47 pm:\r
  86 > Sorry I've been so quiet on this recently. I've been a little under the\r
  87 > weather.\r
  88 \r
  89 No worries.\r
  90 \r
  91 > On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements <amdragon@MIT.EDU> wrote:\r
  92 > > Hence my suggestion that, rather than trying to emulate C-style memory\r
  93 > > management in bindings, bindings should create an additional talloc\r
  94 > > reference to the underlying objects and rather than calling\r
  95 > > notmuch_*_destroy during finalization, they should simply unlink this\r
  96 > > additional reference.\r
  97 > \r
  98 > Currently talloc's reference counting interface is hidden behind\r
  99 > _destroy. While this might be a fairly intrusive change, perhaps notmuch\r
 100 > wants to juse expose a pair of reference counting *_ref/unref functions\r
 101 > instead of the *_destroy. Most users would simply need to change\r
 102 > existing *_destroy()s to _unref()s. Furthermore, this would allow\r
 103 > bindings authors to easily ensure non-broken GC behavior.\r
 104 \r
 105 I think the _destroy functions are silly.  They all just call\r
 106 talloc_free and, indeed, it would arguably be incorrect for them to do\r
 107 anything more (any additional cleanup should be in a talloc\r
 108 destructor).  talloc is never explicitly mentioned in lib/notmuch.h\r
 109 (intentionally, I would assume) but talloc-style notions of\r
 110 "ownership" pervade the library documentation.  IMO, the library\r
 111 should just admit to using talloc, rather than try to wrap all of the\r
 112 not-insubstantial talloc functionality a caller may need.\r
 113 \r
 114 In the language of talloc, it's very natural to express the needs of\r
 115 bindings in terms talloc_reference and talloc_unlink.  The bindings\r
 116 could maintain a per-Database context and track their own ownership by\r
 117 adding a talloc reference from this context to each object returned\r
 118 from the bindings; the finalizer would simply unlink the finalized\r
 119 object from this context.  Bindings could also use a global context\r
 120 (though that would obviously be awkward in Haskell without biting the\r
 121 unsafePerformIO bullet).  Alternatively, bindings could use the NULL\r
 122 context, which has the advantage of not actually tracking ownership in\r
 123 talloc, but the disadvantage of making it harder to track down bugs\r
 124 (since any code can reference or unlink from NULL).\r