--- /dev/null
+Return-Path: <thomas@schwinge.name>\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 2F9DC431FB6\r
+ for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 01:45:46 -0800 (PST)\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\r
+ tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable\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 UOvd+mYWrwex for <notmuch@notmuchmail.org>;\r
+ Fri, 28 Jan 2011 01:45:46 -0800 (PST)\r
+Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de\r
+ [80.67.31.36])\r
+ by olra.theworths.org (Postfix) with ESMTP id C2183431FB5\r
+ for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 01:45:45 -0800 (PST)\r
+Received: from [87.180.40.233] (helo=stokes.schwinge.homeip.net)\r
+ by smtprelay02.ispgateway.de with esmtpa (Exim 4.68)\r
+ (envelope-from <thomas@schwinge.name>) id 1Piktj-0007za-0x\r
+ for notmuch@notmuchmail.org; Fri, 28 Jan 2011 10:45:43 +0100\r
+Received: (qmail 18234 invoked from network); 28 Jan 2011 09:45:25 -0000\r
+Received: from kepler.schwinge.homeip.net (192.168.111.7)\r
+ by stokes.schwinge.homeip.net with QMQP; 28 Jan 2011 09:45:25 -0000\r
+Received: (nullmailer pid 18660 invoked by uid 1000);\r
+ Fri, 28 Jan 2011 09:45:25 -0000\r
+From: Thomas Schwinge <thomas@schwinge.name>\r
+To: Carl Worth <cworth@cworth.org>, Austin Clements <amdragon@mit.edu>,\r
+ Jameson Rollins <jrollins@finestructure.net>\r
+Subject: Re: notmuch's idea of concurrency / failing an invocation\r
+In-Reply-To: <87fwsdobpy.fsf@yoom.home.cworth.org>\r
+References: <87fwsetdin.fsf@kepler.schwinge.homeip.net>\r
+ <8762taxk9y.fsf@algae.riseup.net>\r
+ <87vd1a84qj.fsf@servo.finestructure.net>\r
+ <AANLkTi=pPgcPXUN_XTXa0gAkbTR_OF4XxCP-d4-Be2pt@mail.gmail.com>\r
+ <87fwsdobpy.fsf@yoom.home.cworth.org>\r
+User-Agent: Notmuch/0.5-33-g665f77b (http://notmuchmail.org) Emacs/23.2.1\r
+ (i486-pc-linux-gnu)\r
+Date: Fri, 28 Jan 2011 10:45:19 +0100\r
+Message-ID: <877hdps6og.fsf@kepler.schwinge.homeip.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+ micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-Df-Sender: thomas@schwinge.name\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: Fri, 28 Jan 2011 09:45:46 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+Hallo!\r
+\r
+On Fri, 28 Jan 2011 15:10:01 +1000, Carl Worth <cworth@cworth.org> wrote:\r
+> On Thu, 27 Jan 2011 17:20:21 -0500, Austin Clements <amdragon@mit.edu> wr=\r
+ote:\r
+> > I'm looking into breaking notmuch new up into small transactions. It\r
+> > wouldn't be much a leap from there to simply close and reopen the datab=\r
+ase\r
+> > between transactions if another task wants to use it, which would relea=\r
+se\r
+> > the lock and let the queued notmuch task have the database for a bit.\r
+>=20\r
+> That sounds like something very useful to pursue. Please continue!\r
+\r
+Ack! And actually -- I just wondered about that: what happens if\r
+``notmuch new'' has executed notmuch_database_add_message for a new\r
+message M, but then is killed before adding any tags and finishing up\r
+(and supposing that the DB isn't in an invalid state now). This process\r
+of adding M to the DB and applying any tags isn't one single transaction\r
+currently, right? (And this is exactly what you're working on\r
+chainging?) Am I right that what currently happens is that upon the next\r
+``notmuch new'' run, notmuch will not reconsider M (given that it already\r
+is present in the DB), but continue with the next messages -- thus\r
+leaving M without any tags? This isn't a very likely scenario, but still\r
+a possible one.\r
+\r
+> > It seems silly to have a daemon when all of notmuch's state is already =\r
+on disk\r
+> > and queue on a lock is as good as a queue in a daemon, but without the\r
+> > accompanying architectural shenanigans.\r
+\r
+Ack, too. A daemon seems one abstraction layer too much. (But I'm not\r
+actively opposed either, if someone has a valid use for such a scheme.)\r
+\r
+> It would definitely be nice to avoid the complexity inherent in having a\r
+> daemon, but how do you imagine "queue on a lock" to work? We don't have\r
+> anything like that in place now.\r
+\r
+I suppose what he means is trying to get the lock, and if that fails wait\r
+a bit / wait until it is available again.\r
+\r
+Actually, as a next step, wouldn't it also be possible to add some\r
+heuristic to avoid ``notmuch new'' (being a low-priority task) blocking\r
+some interactive user (UI; high-priority task)? But we can pursue such\r
+schemes as soon as the basic infrastructure is in place.\r
+\r
+> Another advantage that can happen with queueing (wherever it occurs) is\r
+> to allow a client to be very responsive without waiting for an operation\r
+> to complete. Though that can of course be band if the operation isn't\r
+> reliably committed.\r
+\r
+(Obviously this can only work as long as we don't immediatelly need the\r
+operation's result; think ``notmuch show''.)\r
+\r
+So, if the DB has the functionality to internally queue and immediatelly\r
+acknowledge transactions, and only later (reliably) commit them, wouldn't\r
+that be fine indeed? For example, ``notmuch tag'' then wouldn't have to\r
+wait for the DB to be writable. (And note that I have no idea whether\r
+Xapian supports such things.) But on the other hand we would like to\r
+immediatelly display the requested change in the UI, right?\r
+\r
+What notmuch-show.el:notmuch-show-remove-tag currently does is *not*\r
+re-asking the DB for a message's current tags after having removed a\r
+specific one, but instead it interprets the tag removal command itself --\r
+which is easy enough in this case, and rather unlikely to ever yield\r
+different results, at least unless there's another process operating on\r
+the DB concurrently.\r
+\r
+Otherwise, the other way round, the client could maintain a list of to-do\r
+items, to which actions are added if the DB is currently busy, and this\r
+list is periodically worked on in order to get it empty. For example,\r
+tag changes that are in this list, but not yet committed in the DB could\r
+be displayed in another color in the UI. But doing so would shift the\r
+responsibility to the UI, which should be in the DB, in my humble\r
+opinion. (Actually, this issue feels similar to the one who should be\r
+doing the re-trying in case the DB is busy: the UI, or the notmuch\r
+process itself, which we're discussing in another thread.)\r
+\r
+\r
+As you can guess I'm not very much into DBs, and neither too much into\r
+concurrent systems, so if my ideas don't make sense, please feel free to\r
+refer me to literature.\r
+\r
+\r
+Gr=C3=BC=C3=9Fe,\r
+ Thomas\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iEYEARECAAYFAk1CkC8ACgkQFaWaPJ2HwAoguwCcCn2F8JpKLEehzryPb3iRFhD1\r
+2R0AnjOS0Swp28eBpFTyng1VAI6oHX7P\r
+=dhDz\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r
projects / notmuch-archives.git / commitdiff