d9/948cc5f07025bbe61945b0778dfbeb1d018ada

   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 1B611431FB6\r
   6         for <notmuch@notmuchmail.org>; Wed, 18 Apr 2012 10:54:56 -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 zq9YFreSjHto for <notmuch@notmuchmail.org>;\r
  16         Wed, 18 Apr 2012 10:54:55 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU\r
  18         [18.9.25.15])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 4F664431FAE\r
  20         for <notmuch@notmuchmail.org>; Wed, 18 Apr 2012 10:54:55 -0700 (PDT)\r
  21 X-AuditID: 1209190f-b7f8a6d000000914-f3-4f8effeda258\r
  22 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])\r
  23         by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 4D.F3.02324.DEFFE8F4; Wed, 18 Apr 2012 13:54:54 -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 q3IHsqrG012012; \r
  27         Wed, 18 Apr 2012 13:54:53 -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 q3IHsojh017006\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Wed, 18 Apr 2012 13:54:51 -0400 (EDT)\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1SKZ5e-0001EK-Df; Wed, 18 Apr 2012 13:54:50 -0400\r
  37 Date: Wed, 18 Apr 2012 13:54:50 -0400\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Mark Walters <markwalters1009@gmail.com>\r
  40 Subject: Re: [RFC] Split notmuch_database_close into two functions\r
  41 Message-ID: <20120418175450.GR13549@mit.edu>\r
  42 References:\r
  43  <1332291311-28954-1-git-send-email-4winter@informatik.uni-hamburg.de>\r
  44         <20120401032323.GH5949@mit.edu>\r
  45         <20120412090533.2074.78211@thinkbox.jade-hamburg.de>\r
  46         <20120412165744.GF13549@mit.edu> <87mx6a4uls.fsf@qmul.ac.uk>\r
  47 MIME-Version: 1.0\r
  48 Content-Type: text/plain; charset=us-ascii\r
  49 Content-Disposition: inline\r
  50 In-Reply-To: <87mx6a4uls.fsf@qmul.ac.uk>\r
  51 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  52 X-Brightmail-Tracker:\r
  53  H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IR4hTV1n33v8/f4PwNJovZrT+YLFbP5bG4\r
  54         fnMmswOzx85Zd9k9Jp4/zebxbNUt5gDmKC6blNSczLLUIn27BK6MOz/fshf8UKj43XKNrYFx\r
  55         q1QXIyeHhICJxKR/3UwQtpjEhXvr2boYuTiEBPYxSsxavIkdwtnAKLH73W9GCOckk8TFtyvZ\r
  56         QVqEBJYwSrxsjAGxWQRUJW7N2MAGYrMJaEhs27+cEcQWEdCRuH1oAVg9s4CfxL0rV1lAbGEB\r
  57         J4k1FyYBxTk4eIFqWtemQ8x/zSjRfe0JWA2vgKDEyZkQNrOAlsSNfy+ZQOqZBaQllv/jAAlz\r
  58         Aq06d3UiK4gtKqAiMeXkNrYJjEKzkHTPQtI9C6F7ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzU\r
  59         Il0TvdzMEr3UlNJNjOBAl+TfwfjtoNIhRgEORiUe3s/X+vyFWBPLiitzDzFKcjApifJe/wsU\r
  60         4kvKT6nMSCzOiC8qzUktPsQowcGsJMK77gJQjjclsbIqtSgfJiXNwaIkzqum9c5PSCA9sSQ1\r
  61         OzW1ILUIJivDwaEkwVsOjGghwaLU9NSKtMycEoQ0EwcnyHAeoOEFIDW8xQWJucWZ6RD5U4yK\r
  62         UuK8biAJAZBERmkeXC8sEb1iFAd6RZg3AaSKB5jE4LpfAQ1mAhqsKAE2uCQRISXVwMikMCci\r
  63         pC9D9F/qedY7+/8K69868iqZ72he++sTpSvLPkWsFmbv1Ak3dbItCC3fmbDocLstxzL+BD+J\r
  64         LrU5fHefs0+ZwvAuImOqBE/XvwmbOtd8WSGZeVF+QsqeOWuFr1fPfNC5uf3YnmnKvn0Zb8qL\r
  65         rJPjdSXLKxLOstUIF+91uxPocj37rhJLcUaioRZzUXEiAAej/zcfAwAA\r
  66 Cc: notmuch@notmuchmail.org\r
  67 X-BeenThere: notmuch@notmuchmail.org\r
  68 X-Mailman-Version: 2.1.13\r
  69 Precedence: list\r
  70 List-Id: "Use and development of the notmuch mail system."\r
  71         <notmuch.notmuchmail.org>\r
  72 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  73         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  74 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  75 List-Post: <mailto:notmuch@notmuchmail.org>\r
  76 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  77 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  78         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  79 X-List-Received-Date: Wed, 18 Apr 2012 17:54:56 -0000\r
  80 \r
  81 Quoth Mark Walters on Apr 17 at  9:42 am:\r
  82 > On Thu, 12 Apr 2012, Austin Clements <amdragon@MIT.EDU> wrote:\r
  83 > > Quoth Justus Winter on Apr 12 at 11:05 am:\r
  84 > >> Quoting Austin Clements (2012-04-01 05:23:23)\r
  85 > >> >Quoth Justus Winter on Mar 21 at  1:55 am:\r
  86 > >> >> I propose to split the function notmuch_database_close into\r
  87 > >> >> notmuch_database_close and notmuch_database_destroy so that long\r
  88 > >> >> running processes like alot can close the database while still using\r
  89 > >> >> data obtained from queries to that database.\r
  90 > >> >\r
  91 > >> >Is this actually safe?  My understanding of Xapian::Database::close is\r
  92 > >> >that, once you've closed the database, basically anything can throw a\r
  93 > >> >Xapian exception.  A lot of data is retrieved lazily, both by notmuch\r
  94 > >> >and by Xapian, so simply having, say, a notmuch_message_t object isn't\r
  95 > >> >enough to guarantee that you'll be able to get data out of it after\r
  96 > >> >closing the database.  Hence, I don't see how this interface could be\r
  97 > >> >used correctly.\r
  98 > >> \r
  99 > >> I do not know how, but both alot and afew (and occasionally the\r
 100 > >> notmuch binary) are somehow safely using this interface on my box for\r
 101 > >> the last three weeks.\r
 102 > >\r
 103 > > I see.  TL;DR: This isn't safe, but that's okay if we document it.\r
 104 > >\r
 105 > > The bug report [0] you pointed to was quite informative.  At its core,\r
 106 > > this is really a memory management issue.  To sum up for the record\r
 107 > > (and to check my own thinking): It sounds like alot is careful not to\r
 108 > > use any notmuch objects after closing the database.  The problem is\r
 109 > > that, currently, closing the database also talloc_free's it, which\r
 110 > > recursively free's everything derived from it.  Python later GCs the\r
 111 > > wrapper objects, which *also* try to free their underlying objects,\r
 112 > > resulting in a double free.\r
 113 > >\r
 114 > > Before the change to expose notmuch_database_close, the Python\r
 115 > > bindings would only talloc_free from destructors.  Furthermore, they\r
 116 > > prevented the library from recursively freeing things at other times\r
 117 > > by internally maintaining a reverse reference for every library talloc\r
 118 > > reference (e.g., message is a sub-allocation of query, so the bindings\r
 119 > > keep a reference from each message to its query to ensure the query\r
 120 > > doesn't get freed).  The ability to explicitly talloc_free the\r
 121 > > database subverts this mechanism.\r
 122 > >\r
 123 > >\r
 124 > > So, I've come around to thinking that splitting notmuch_database_close\r
 125 > > and _destroy is okay.  It certainly parallels the rest of the API\r
 126 > > better.  However, notmuch_database_close needs a big warning similar\r
 127 > > to Xapian::Database::close's warning that retrieving information from\r
 128 > > objects derived from this database may not work after calling close.\r
 129 > > notmuch_database_close is really a specialty interface, and about the\r
 130 > > only thing you can guarantee after closing the database is that you\r
 131 > > can destroy other objects.  This is also going to require a SONAME\r
 132 > > major version bump, as mentioned by others.  Which, to be fair, would\r
 133 > > be a good opportunity to fix some other issues, too, like how\r
 134 > > notmuch_database_open can't return errors and how\r
 135 > > notmuch_database_get_directory is broken on read-only databases.  The\r
 136 > > actual bump should be done at release time, but maybe we should drop a\r
 137 > > note somewhere (NEWS?) so we don't forget.\r
 138 > \r
 139 > Can I just check that there is no way to reopen the Xapian database\r
 140 > readonly? (I may be using the wrong term: I mean is there a way of\r
 141 > switching an open read-write database to read-only without losing the\r
 142 > attached structures/messages/threads etc) If I understand it this would\r
 143 > be sufficient as it would free the lock, but could be more generally\r
 144 > useful for long lived notmuch processes.\r
 145 \r
 146 That would be handy and perfect for this situation, but no (I\r
 147 double-checked with Olly on IRC, which you probably saw).  We might be\r
 148 able to lobby for this capability if it seems more generally useful.\r
 149 On the other hand, I think it would probably mix poorly with Xapian's\r
 150 optimistic snapshot isolation if we tried to use it for anything\r
 151 non-trivial (combined with real snapshot isolation it would be\r
 152 awesome).\r