52/cb44519cba898eeb16bd046f33294eae330004

   1 Return-Path: <cworth@cworth.org>\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 9E469429E25\r
   6         for <notmuch@notmuchmail.org>; Mon, 19 Sep 2011 15:27:18 -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.01\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.01 tagged_above=-999 required=5\r
  12         tests=[T_MIME_NO_TEXT=0.01] 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 ou8xSlYLsI85 for <notmuch@notmuchmail.org>;\r
  16         Mon, 19 Sep 2011 15:27:18 -0700 (PDT)\r
  17 Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2])\r
  18         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id D81C3431FB6\r
  21         for <notmuch@notmuchmail.org>; Mon, 19 Sep 2011 15:27:17 -0700 (PDT)\r
  22 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  23         by arlo.cworth.org (Postfix) with ESMTP id EBABA356560;\r
  24         Mon, 19 Sep 2011 15:27:14 -0700 (PDT)\r
  25 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  26         id AB85625415A; Mon, 19 Sep 2011 15:27:14 -0700 (PDT)\r
  27 From: Carl Worth <cworth@cworth.org>\r
  28 To: Ben Gamari <bgamari.foss@gmail.com>, notmuch <notmuch@notmuchmail.org>\r
  29 Subject: Re: Rethinking *_destroy()\r
  30 In-Reply-To: <87aaa0l1tc.fsf@gmail.com>\r
  31 References: <87aaa0l1tc.fsf@gmail.com>\r
  32 User-Agent: Notmuch/0.8 (http://notmuchmail.org) Emacs/23.3.1\r
  33         (i486-pc-linux-gnu)\r
  34 Date: Mon, 19 Sep 2011 15:27:08 -0700\r
  35 Message-ID: <87obygxj5v.fsf@yoom.home.cworth.org>\r
  36 MIME-Version: 1.0\r
  37 Content-Type: multipart/signed; boundary="=-=-=";\r
  38         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  39 Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,\r
  40         notmuch <notmuch@notmuchmail.org>, Austin Clements <amdragon@MIT.EDU>,\r
  41         Bart Massey <bart@cs.pdx.edu>\r
  42 X-BeenThere: notmuch@notmuchmail.org\r
  43 X-Mailman-Version: 2.1.13\r
  44 Precedence: list\r
  45 List-Id: "Use and development of the notmuch mail system."\r
  46         <notmuch.notmuchmail.org>\r
  47 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  48         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  49 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  50 List-Post: <mailto:notmuch@notmuchmail.org>\r
  51 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  52 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  54 X-List-Received-Date: Mon, 19 Sep 2011 22:27:18 -0000\r
  55 \r
  56 --=-=-=\r
  57 Content-Transfer-Encoding: quoted-printable\r
  58 \r
  59 On Mon, 19 Sep 2011 16:22:39 -0400, Ben Gamari <bgamari.foss@gmail.com> wro=\r
  60 te:\r
  61 > As many might have noticed, there was recently a bit of a discussion on\r
  62 > this list concerning the state of memory management in libnotmuch,\r
  63 > especially regarding some classes of garbage collectors.\r
  64 >=20\r
  65 > To summarize (someone correct me if I get something wrong),\r
  66 \r
  67 Thanks for the summary, Ben. As many might have noticed, I'm somewhat\r
  68 behind on my reading of the notmuch mailing list right now. So I\r
  69 appreciate you bringing this issue to my attention.\r
  70 \r
  71 > Overall, this means that languages with cyclical garbage collectors\r
  72 > (Python, Haskell, and I'm sure others) can not bind libnotmuch\r
  73 > correctly.\r
  74 \r
  75 That certainly sound unappealing.\r
  76 \r
  77 > I can see at least two ways of doing this,\r
  78 >=20\r
  79 >   1) Acknowledging that we use talloc and allowing users to use\r
  80 >      talloc_ref and talloc_unlink directly\r
  81 \r
  82 I like this option, myself. I think talloc has been a wonderful boon to\r
  83 my programming. So I don't have a problem with the notmuch API\r
  84 documentation committing the implementation to using talloc. I'm also\r
  85 quite glad to let the notmuch documentation advertise talloc to any\r
  86 readers.\r
  87 \r
  88 >   2) Wrapping talloc by adding a *_ref() and *_unref() to each object\r
  89 \r
  90 That looks like a lot of extra API, but with no substantial benefit. (We\r
  91 would get the freedom to switch to some other implementation of talloc,\r
  92 but, I don't think we need that.)\r
  93 \r
  94 > Additionally, we need to decide to what extent we want to break the\r
  95 > libnotmuch API. While strictly speaking we could keep *_destroy() around\r
  96 > without breaking existing code, this will mean we will have two ways of\r
  97 > freeing an object. Perhaps a scheduled deprecation in a release or two\r
  98 > is in order here?\r
  99 \r
 100 Actually, I would prefer to leave *_destroy around, (as long as it's\r
 101 doing nothing other than tall_free (or talloc_unlink? [*]) which does\r
 102 appear to be the case for all existing functions).\r
 103 \r
 104 To me, it doesn't really look like two ways of freeing an object.\r
 105 Anyone who calls notmuch_query_create, (for example), should call\r
 106 notmuch_query_destroy and those two calls pair nicely.\r
 107 \r
 108 Then, *some* callers will want to take advantage of talloc. Those users\r
 109 can add calls to talloc_reference and talloc_unlink (which pair nicely\r
 110 themselves).\r
 111 \r
 112 What I don't want is the unnatural pairing of something like\r
 113 "notmuch_query_create" with "talloc_unlink". That just seems uselessly\r
 114 harder to learn and remember.\r
 115 \r
 116 > Any and all feedback is desired.\r
 117 \r
 118 Thanks for pointing out the issue. Let me know if I've missed\r
 119 anything. And, happy binding!\r
 120 \r
 121 =2DCarl\r
 122 \r
 123 [*] These destroy() functions are all currently calling talloc_free()\r
 124 which won't work if the user has any remaining parents still present due\r
 125 to calls to talloc_reference(). Perhaps we can just document that all\r
 126 talloc_reference()/talloc_unlink() pairs must be complete before the\r
 127 caller calls _destroy()?\r
 128 \r
 129 =2D-=20\r
 130 carl.d.worth@intel.com\r
 131 \r
 132 --=-=-=\r
 133 Content-Type: application/pgp-signature\r
 134 \r
 135 -----BEGIN PGP SIGNATURE-----\r
 136 Version: GnuPG v1.4.11 (GNU/Linux)\r
 137 \r
 138 iEYEARECAAYFAk53wbwACgkQ6JDdNq8qSWj44QCfaFAeMLgdU31BYNOirx6dMyB6\r
 139 f10An1S7lBIKNteWoY4W94NZjb4LTBxp\r
 140 =1uVb\r
 141 -----END PGP SIGNATURE-----\r
 142 --=-=-=--\r