78/6cb4df3393c6e1ce9e9d98f160a64699185ea2

   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 6219E429E26\r
   6         for <notmuch@notmuchmail.org>; Fri,  9 Sep 2011 10:51:02 -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 KuUa1h2807sf for <notmuch@notmuchmail.org>;\r
  16         Fri,  9 Sep 2011 10:51:01 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-7.mit.edu (DMZ-MAILSEC-SCANNER-7.MIT.EDU\r
  18         [18.7.68.36])\r
  19         by olra.theworths.org (Postfix) with ESMTP id AF0A5431FB6\r
  20         for <notmuch@notmuchmail.org>; Fri,  9 Sep 2011 10:51:01 -0700 (PDT)\r
  21 X-AuditID: 12074424-b7bcaae000000a05-78-4e6a523e1fe6\r
  22 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])\r
  23         by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id E5.A8.02565.E325A6E4; Fri,  9 Sep 2011 13:51:58 -0400 (EDT)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p89Hoxua027925; \r
  27         Fri, 9 Sep 2011 13:51:00 -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 p89HowDL020438\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Fri, 9 Sep 2011 13:50:59 -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 1R25Ga-000685-Al; Fri, 09 Sep 2011 13:53:28 -0400\r
  37 Date: Fri, 9 Sep 2011 13:53:28 -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: <20110909175328.GV5688@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> <20110908151557.GM5688@mit.edu>\r
  48         <8762l22hgk.fsf@SSpaeth.de>\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: <8762l22hgk.fsf@SSpaeth.de>\r
  53 User-Agent: Mutt/1.5.20 (2009-06-14)\r
  54 X-Brightmail-Tracker:\r
  55  H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsUixCmqrGsXlOVncOy/iEXj33tMFjOf7GW2\r
  56         WL5KyuL6zZnMFrPmzGN0YPV4vXoaq8fOWXfZPZ5OmMzu8WzVLWaPxV+WsgSwRnHZpKTmZJal\r
  57         FunbJXBlrL6/gb3gnGjFloU/WRoYXwl2MXJySAiYSCzo3M0CYYtJXLi3nq2LkYtDSGAfo8TP\r
  58         8yehnPWMEs/+vGKEcE4wSbz++YkFwlnCKDHx0zQ2kH4WARWJ283/2EFsNgENiW37lzOC2CIC\r
  59         2hJHW3awgjQwC2xllPj3rgmsSBioaOaDbrBmXqCi3rmn2SGmrmCWOHrxCiNEQlDi5MwnYBcy\r
  60         C2hJ3Pj3kqmLkQPIlpZY/o8DJMwJNOdb30SwmaJAR1zb3842gVFoFpLuWUi6ZyF0L2BkXsUo\r
  61         m5JbpZubmJlTnJqsW5ycmJeXWqRrrpebWaKXmlK6iREUF+wuKjsYmw8pHWIU4GBU4uFdaZrl\r
  62         J8SaWFZcmXuIUZKDSUmUNzsQKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEN04CKMebklhZlVqU\r
  63         D5OS5mBREue12engJySQnliSmp2aWpBaBJOV4eBQkuDNAxkqWJSanlqRlplTgpBm4uAEGc4D\r
  64         NPxpAMjw4oLE3OLMdIj8KUZjjvNrrx9n5Dh0+NZxRiGWvPy8VClxXlOQcQIgpRmleXDTYKnt\r
  65         FaM40HPCvIkgVTzAtAg37xXQKiagVQHbM0FWlSQipKQaGGt2/njcXqWUy8qybdeXbfd+1aaL\r
  66         8B40Xr/trMmeVrlI24fL7n3sTtFZ+OzSfYE7m9evsHqZr9ip+XVny2pjrZPiOXdMlxrN9Kkr\r
  67         2Pkw9eT3lj0M2+7cvG2iV7YnOWVyz72rqtvWeWR/K+9sr8y8YyBZs7pEsK3OfmtU7jerbRV7\r
  68         44oOf1luGqPEUpyRaKjFXFScCAC+6weZSAMAAA==\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: Fri, 09 Sep 2011 17:51:02 -0000\r
  84 \r
  85 Quoth Sebastian Spaeth on Sep 09 at 11:27 am:\r
  86 > On Thu, 8 Sep 2011 11:15:57 -0400, Austin Clements <amdragon@MIT.EDU> wrote:\r
  87 > > In general, a garbage collector can't make any guarantees about\r
  88 > > finalization order.  When a collection of objects all become\r
  89 > > unreachable simultaneously (for example, the last reference to any\r
  90 > > Messages object is dropped, causing the Query object and the Message\r
  91 > > object to both become unreachable), the garbage collector *could*\r
  92 > > finalize the Query first (causing talloc to free the\r
  93 > > notmuch_messages_t) and then the Messages object (causing it to\r
  94 > > crash).  There's no guarantee in general because, in the presence of\r
  95 > > cycles, there is no meaningful finalization order.\r
  96 > \r
  97 > Right, but that should not pose a problem for python. If e.g. both a\r
  98 > Query and derived Message objects become unreachable, the python objects\r
  99 > would not care which object is ditched and deleted first. Currently, it\r
 100 > seems that we finalize the Messages first, and the Query second. But we\r
 101 > would not fail if the Query were finalized first. Granted, the\r
 102 > underlying libnotmuch Message objects were torn away while the python\r
 103 > Message objects were still around. But they would ultimately also be\r
 104 > sweeped away, and that would not cause any problems.\r
 105 > \r
 106 > But I am sure that I am missing out something. I'll leave this\r
 107 > discussion to the pros :-).\r
 108 \r
 109 Ah, the *Python* objects don't care, but the underlying C objects do.\r
 110 Suppose the Query were finalized first.  Python calls Query.__del__,\r
 111 which calls notmuch_query_destroy, which releases the underlying\r
 112 talloc references to the C notmuch_messages_t objects, causing talloc\r
 113 to free the notmuch_messages_t.  Messages._msgs now points to freed\r
 114 memory, so when Python then finalizes the Messages object,\r
 115 Messages.__del__ will pass this dangling pointer to\r
 116 notmuch_messages_destroy, which will crash.\r
 117 \r
 118 Hence my suggestion that, rather than trying to emulate C-style memory\r
 119 management in bindings, bindings should create an additional talloc\r
 120 reference to the underlying objects and rather than calling\r
 121 notmuch_*_destroy during finalization, they should simply unlink this\r
 122 additional reference.  Any remaining library-created references will\r
 123 keep the object alive as long as it's still needed by the library.\r
 124 Then there's also no need to replicate the library's reference\r
 125 structure in the bindings (though there is a danger of needlessly\r
 126 delaying free's when the library creates convenience references like\r
 127 the one from notmuch_query_t to notmuch_messages_t; for these I'd\r
 128 recommend that the bindings undo such references, which requires a\r
 129 little knowledge of the library's reference structure, but nothing\r
 130 beyond what should be documented).\r