e9/79234eb2f81dab370c2a66b7dfd8b58177908d

   1 Return-Path: <m.walters@qmul.ac.uk>\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 C9AED431FB6\r
   6         for <notmuch@notmuchmail.org>; Tue, 17 Apr 2012 01:42:38 -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: -1.098\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id mvQIniGsOOzB for <notmuch@notmuchmail.org>;\r
  17         Tue, 17 Apr 2012 01:42:38 -0700 (PDT)\r
  18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 0F77C431FAE\r
  22         for <notmuch@notmuchmail.org>; Tue, 17 Apr 2012 01:42:38 -0700 (PDT)\r
  23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  25         (envelope-from <m.walters@qmul.ac.uk>)\r
  26         id 1SK3zf-00043w-Aq; Tue, 17 Apr 2012 09:42:35 +0100\r
  27 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
  28         helo=localhost)\r
  29         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
  30         (envelope-from <m.walters@qmul.ac.uk>)\r
  31         id 1SK3ze-0001IF-PN; Tue, 17 Apr 2012 09:42:34 +0100\r
  32 From: Mark Walters <markwalters1009@gmail.com>\r
  33 To: Austin Clements <amdragon@MIT.EDU>,\r
  34         Justus Winter <4winter@informatik.uni-hamburg.de>\r
  35 Subject: Re: [RFC] Split notmuch_database_close into two functions\r
  36 In-Reply-To: <20120412165744.GF13549@mit.edu>\r
  37 References:\r
  38  <1332291311-28954-1-git-send-email-4winter@informatik.uni-hamburg.de>\r
  39         <20120401032323.GH5949@mit.edu>\r
  40         <20120412090533.2074.78211@thinkbox.jade-hamburg.de>\r
  41         <20120412165744.GF13549@mit.edu>\r
  42 User-Agent: Notmuch/0.12+110~gbc97b4a (http://notmuchmail.org) Emacs/23.3.1\r
  43         (x86_64-pc-linux-gnu)\r
  44 Date: Tue, 17 Apr 2012 09:42:55 +0100\r
  45 Message-ID: <87mx6a4uls.fsf@qmul.ac.uk>\r
  46 MIME-Version: 1.0\r
  47 Content-Type: text/plain; charset=us-ascii\r
  48 X-Sender-Host-Address: 94.192.233.223\r
  49 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  50 X-QM-Body-MD5: 193c4160caa46f9f63d218ae448bbf9e (of first 20000 bytes)\r
  51 X-SpamAssassin-Score: -1.8\r
  52 X-SpamAssassin-SpamBar: -\r
  53 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  54         determine if it is\r
  55         spam. We require at least 5.0 points to mark a message as spam.\r
  56         This message scored -1.8 points.\r
  57         Summary of the scoring: \r
  58         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
  59         *      medium trust\r
  60         *      [138.37.6.40 listed in list.dnswl.org]\r
  61         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  62         provider *      (markwalters1009[at]gmail.com)\r
  63         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
  64         *      domain\r
  65         *  0.5 AWL AWL: From: address is in the auto white-list\r
  66 X-QM-Scan-Virus: ClamAV says the message is clean\r
  67 Cc: notmuch@notmuchmail.org\r
  68 X-BeenThere: notmuch@notmuchmail.org\r
  69 X-Mailman-Version: 2.1.13\r
  70 Precedence: list\r
  71 List-Id: "Use and development of the notmuch mail system."\r
  72         <notmuch.notmuchmail.org>\r
  73 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  74         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  75 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  76 List-Post: <mailto:notmuch@notmuchmail.org>\r
  77 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  78 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  79         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  80 X-List-Received-Date: Tue, 17 Apr 2012 08:42:38 -0000\r
  81 \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 Best wishes\r
 147 \r
 148 Mark\r