59/8f5e74cd90d641039c98773eddb70a601a3bc2

   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 07A44431FD0\r
   6         for <notmuch@notmuchmail.org>; Thu,  8 Sep 2011 08:13:34 -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 sZi5uOgtnYyH for <notmuch@notmuchmail.org>;\r
  16         Thu,  8 Sep 2011 08:13:33 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU\r
  18         [18.9.25.12])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 73689431FB6\r
  20         for <notmuch@notmuchmail.org>; Thu,  8 Sep 2011 08:13:33 -0700 (PDT)\r
  21 X-AuditID: 1209190c-b7b06ae000000aad-5e-4e68db6d6ac6\r
  22 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
  23         by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 30.C7.02733.D6BD86E4; Thu,  8 Sep 2011 11:12:45 -0400 (EDT)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p88FDTpI023371; \r
  27         Thu, 8 Sep 2011 11:13:29 -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 p88FDRYW005253\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Thu, 8 Sep 2011 11:13:28 -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 1R1gKb-0003mu-RK; Thu, 08 Sep 2011 11:15:57 -0400\r
  37 Date: Thu, 8 Sep 2011 11:15:57 -0400\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Sebastian Spaeth <Sebastian@sspaeth.de>\r
  40 Subject: Re: Memory management practices\r
  41 Message-ID: <20110908151557.GM5688@mit.edu>\r
  42 References: <8739h1pbaq.fsf@gmail.com> <87pqjprzu2.fsf@gmail.com>\r
  43         <20110829183010.GA2605@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>\r
  44         <87liucyn7i.fsf@gmail.com> <87aaag3xaf.fsf@gmail.com>\r
  45         <CAH-f9WsfHUm_D-+wB89Lt9Wt=hjwDyywvJTK-0NwmHRg0TUsxQ@mail.gmail.com>\r
  46         <CAH-f9WveBfvmv2jOF+C81OeeQJt06g6U0q3J_idHrs60DLw7+g@mail.gmail.com>\r
  47         <87zkiff8in.fsf@SSpaeth.de>\r
  48 MIME-Version: 1.0\r
  49 Content-Type: text/plain; charset=us-ascii\r
  50 Content-Disposition: inline\r
  51 In-Reply-To: <87zkiff8in.fsf@SSpaeth.de>\r
  52 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  53 X-Brightmail-Tracker:\r
  54  H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixCmqrZt7O8PP4HuzqEXj33tMFjOf7GW2\r
  55         WL5KyuL6zZnMFrPmzGN0YPV4vXoaq8fOWXfZPZ5OmMzu8WzVLWaPxV+WsgSwRnHZpKTmZJal\r
  56         FunbJXBldF/vZCs4KVLxoKOPqYHxhEAXIweHhICJxJPLcV2MnECmmMSFe+vZuhi5OIQE9jFK\r
  57         zNl+iQnCWc8ocWLzc2YI5wSTRPejC1CZJYwS717sYwbpZxFQkZjwYwUbiM0moCGxbf9yRhBb\r
  58         REBb4mjLDlaQBmaBrYwS/941sYMkhIGKZj7oBmvgBSr6sesWK8TUF0wSvX8esUIkBCVOznzC\r
  59         AmIzC2hJ3Pj3kgnkcGYBaYnl/zhAwpxAc84/3QR2hCjQEdf2t7NNYBSahaR7FpLuWQjdCxiZ\r
  60         VzHKpuRW6eYmZuYUpybrFicn5uWlFuka6uVmluilppRuYgRHhSTPDsY3B5UOMQpwMCrx8LJN\r
  61         TfcTYk0sK67MPcQoycGkJMrrfCnDT4gvKT+lMiOxOCO+qDQntfgQowQHs5IIb/AJoBxvSmJl\r
  62         VWpRPkxKmoNFSZz34A4HPyGB9MSS1OzU1ILUIpisDAeHkgTvjltAjYJFqempFWmZOSUIaSYO\r
  63         TpDhPEDDn4LU8BYXJOYWZ6ZD5E8x6nK07194nFGIJS8/L1VKnJcVmI6EBECKMkrz4ObAktkr\r
  64         RnGgt4R5n4CM4gEmQrhJr4CWMAEtOZSfCrKkJBEhJdXA2LPs5rK+KdWzkg7M+3vMxCw8U0rP\r
  65         KCAz1fhrv+0qfsWjk56m+AQ8NNkwc8+6O+saA5eyO35u+3Jv5gp1Prtj3ce2VNa7Sgj8NVHg\r
  66         q2d3ct2kZ5799fuFdy9lyhvTxIP9ymNSjZYLN6wwXrZ7y/E/yVknxPIu/w7RCPY5ksg7k/OG\r
  67         bd/h2jMZSizFGYmGWsxFxYkAGifroUEDAAA=\r
  68 Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,\r
  69         Bart Massey <bart@cs.pdx.edu>, notmuch <notmuch@notmuchmail.org>\r
  70 X-BeenThere: notmuch@notmuchmail.org\r
  71 X-Mailman-Version: 2.1.13\r
  72 Precedence: list\r
  73 List-Id: "Use and development of the notmuch mail system."\r
  74         <notmuch.notmuchmail.org>\r
  75 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  76         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  77 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  78 List-Post: <mailto:notmuch@notmuchmail.org>\r
  79 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  80 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  81         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  82 X-List-Received-Date: Thu, 08 Sep 2011 15:13:34 -0000\r
  83 \r
  84 Quoth Sebastian Spaeth on Sep 08 at  3:50 pm:\r
  85 > On Wed, 7 Sep 2011 23:05:19 -0400, Austin Clements <amdragon@mit.edu> wrote:\r
  86 > > Sorry, I went back and re-read your earlier messages and now I see why\r
  87 > > your references were the way they were.  I stand by the rest of my\r
  88 > > previous message though.  I think the technique used in the Python\r
  89 > > bindings only works because Python's GC happens to finalize in a\r
  90 > > particular order (though I doubt that's guaranteed, and could easily\r
  91 > > not be the case if you stray into the realm of its cycle collector).\r
  92 > > In general, it seems like approach is trying to recreate C-like memory\r
  93 > > management and is fragile as a result, whereas talloc should, I think,\r
  94 > > allow bindings to express their runtime's memory management rather\r
  95 > > naturally.\r
  96 > \r
  97 > Mmmh? Why would the method in python be fragile? Each message object\r
  98 > holds a reference to its parent query object to keep it alive. Are you\r
  99 > saying cycle collectors could kill off the query object nonetheless?\r
 100 > (Assume that I know nothing of GCs which comes close to reality)\r
 101 \r
 102 In general, a garbage collector can't make any guarantees about\r
 103 finalization order.  When a collection of objects all become\r
 104 unreachable simultaneously (for example, the last reference to any\r
 105 Messages object is dropped, causing the Query object and the Message\r
 106 object to both become unreachable), the garbage collector *could*\r
 107 finalize the Query first (causing talloc to free the\r
 108 notmuch_messages_t) and then the Messages object (causing it to\r
 109 crash).  There's no guarantee in general because, in the presence of\r
 110 cycles, there is no meaningful finalization order.\r
 111 \r
 112 That being said, this approach might be (probably is) fine in Python\r
 113 because Python has an unusual hybrid garbage collector.  Long ago,\r
 114 Python had only a reference-count based garbage collector.  It now has\r
 115 a cycle detector layered on top of that [1], but that only kicks in if\r
 116 there are reference cycles.  Assuming there aren't cycles in the\r
 117 objects created by the Python bindings, you should get the\r
 118 deterministic behavior of the reference counted collector.  This isn't\r
 119 the case in Haskell, which has a generational collector that makes no\r
 120 guarantees about finalization order (guarantees it couldn't always\r
 121 keep).\r
 122 \r
 123 \r
 124 [1] One day a student came to Moon and said: "I understand how to make\r
 125 a better garbage collector. We must keep a reference count of the\r
 126 pointers to each cons."\r
 127 \r
 128 Moon patiently told the student the following story:\r
 129 \r
 130     "One day a student came to Moon and said: 'I understand how to\r
 131     make a better garbage collector...\r