--- /dev/null
+Return-Path: <teythoon@jade-hamburg.de>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id E5605431FAF\r
+ for <notmuch@notmuchmail.org>; Thu, 12 Apr 2012 02:05:44 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
+ autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id yZ1fjiln2LuU for <notmuch@notmuchmail.org>;\r
+ Thu, 12 Apr 2012 02:05:42 -0700 (PDT)\r
+Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68])\r
+ (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 47BF7431FAE\r
+ for <notmuch@notmuchmail.org>; Thu, 12 Apr 2012 02:05:42 -0700 (PDT)\r
+Received: from mail.jade-hamburg.de (unknown [85.183.11.228])\r
+ (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by mail.cryptobitch.de (Postfix) with ESMTPSA id 08B8656A613\r
+ for <notmuch@notmuchmail.org>; Thu, 12 Apr 2012 11:05:40 +0200 (CEST)\r
+Received: by mail.jade-hamburg.de (Postfix, from userid 401)\r
+ id 57F4BDF2A3; Thu, 12 Apr 2012 11:05:39 +0200 (CEST)\r
+Received: from thinkbox.jade-hamburg.de (unknown [193.174.12.196])\r
+ (using TLSv1 with cipher AES256-SHA (256/256 bits))\r
+ (No client certificate requested) (Authenticated sender: teythoon)\r
+ by mail.jade-hamburg.de (Postfix) with ESMTPSA id 18186DF2A0;\r
+ Thu, 12 Apr 2012 11:05:35 +0200 (CEST)\r
+Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.77)\r
+ (envelope-from <teythoon@thinkbox.jade-hamburg.de>)\r
+ id 1SIFy9-0005cO-7n; Thu, 12 Apr 2012 11:05:33 +0200\r
+Content-Type: text/plain; charset="utf-8"\r
+MIME-Version: 1.0\r
+Content-Transfer-Encoding: quoted-printable\r
+To: Austin Clements <amdragon@MIT.EDU>\r
+From: Justus Winter <4winter@informatik.uni-hamburg.de>\r
+In-Reply-To: <20120401032323.GH5949@mit.edu>\r
+References:\r
+ <1332291311-28954-1-git-send-email-4winter@informatik.uni-hamburg.de>\r
+ <20120401032323.GH5949@mit.edu>\r
+Message-ID: <20120412090533.2074.78211@thinkbox.jade-hamburg.de>\r
+User-Agent: alot/0.21+\r
+Subject: Re: [RFC] Split notmuch_database_close into two functions\r
+Date: Thu, 12 Apr 2012 11:05:33 +0200\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 12 Apr 2012 09:05:45 -0000\r
+\r
+Quoting Austin Clements (2012-04-01 05:23:23)\r
+>Quoth Justus Winter on Mar 21 at 1:55 am:\r
+>> I propose to split the function notmuch_database_close into\r
+>> notmuch_database_close and notmuch_database_destroy so that long\r
+>> running processes like alot can close the database while still using\r
+>> data obtained from queries to that database.\r
+>\r
+>Is this actually safe? My understanding of Xapian::Database::close is\r
+>that, once you've closed the database, basically anything can throw a\r
+>Xapian exception. A lot of data is retrieved lazily, both by notmuch\r
+>and by Xapian, so simply having, say, a notmuch_message_t object isn't\r
+>enough to guarantee that you'll be able to get data out of it after\r
+>closing the database. Hence, I don't see how this interface could be\r
+>used correctly.\r
+\r
+I do not know how, but both alot and afew (and occasionally the\r
+notmuch binary) are somehow safely using this interface on my box for\r
+the last three weeks.\r
+\r
+>Maybe you could describe your use case in more detail?\r
+\r
+Uh, okay. There are two long running processes (alot and afew in my\r
+case) competing for a resource ("writable access to the notmuch\r
+database"). This access is serialized by a lock maintained by\r
+libxapian. This is a rather classic cs problem.\r
+\r
+In order to avoid starvation of one process, both processes must\r
+release the lock after a finite amount of time. Now for all practical\r
+purposes the requirement is usually that both processes should\r
+minimize the time spent while they aquired the lock.\r
+\r
+The only way to ensure that the lock is released is to ask notmuch to\r
+release the lock. When Patrick asked me for a way to release the lock\r
+I exposed the function notmuch_database_close [0].\r
+\r
+I made a mistake. The mistake was to assume that a function named\r
+notmuch_database_close would actually do as the name implies. But that\r
+wasn't the case. I should have been more suspicious, but being\r
+somewhat naive I patched notmuch_database_close to actually close the\r
+database [1].\r
+\r
+I'm basically trying to correct that mistake. One way to fix that is\r
+this patchset, the other one is to rename notmuch_database_close to\r
+notmuch_database_destroy and to remove the ability to call this\r
+function from the python bindings.\r
+\r
+There is a branch of alot [2] that needs this functionality and hence\r
+this patchset to avoid crashes (the ticket contains more information\r
+why this leads to crashes). Incidentally this branch also fixes\r
+another bug in alot [3]. Patrick spoke up in this thread stating that\r
+this patchset is useful for alot. There is a unpublished branch of\r
+afew that requires this functionality.\r
+\r
+I think it very much boils down to the question whether or not\r
+libnotmuch and its users are second class citizens. This issue is not\r
+a problem for the notmuch binary since it is short lived in nature.\r
+\r
+In fact I feel reminded of [4] when I pointed out problems in the code\r
+that are problematic for libnotmuch users. You - Austin - suggested to\r
+whip up patches instead of raising concerns. That's a valid response,\r
+after all, talk is cheap ;)\r
+\r
+But now that I have a patchset that is rather small (yes, it changes\r
+the API but any program can be adjusted automatically using sed...)\r
+and I kind of thought that it would be accepted more easily. And\r
+although the changes are trivial it took me quite some time to track\r
+it down.\r
+\r
+The thread [4] dried out without someone like you or David stating\r
+that he cares about libnotmuch and its users as much as the users of\r
+the notmuch binary. These kind of problems require invasive code and\r
+API changes, I asked in that very same thread how to do this properly\r
+but noone answered.\r
+\r
+I think I'm just not willing to devote my time to fix these problems\r
+if these issues aren't even perceived as problems by the majority of\r
+notmuch users and developers b/c they are using the emacs interface\r
+which just calls the notmuch binary that has no such problems.\r
+\r
+Cheers,\r
+Justus\r
+\r
+0: b2734519db78fdec76eeafc5fe8f5631a6436cf6\r
+1: cfc5f1059aa16753cba610c41601cacc97260e08\r
+2: https://github.com/pazz/alot/issues/413\r
+3: https://github.com/pazz/alot/issues/414\r
+4: 20120221002921.8534.57091@thinkbox.jade-hamburg.de\r
projects / notmuch-archives.git / commitdiff