DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type
	:content-transfer-encoding;
	b=OB3D+mtI8PT4+DP4wgiCdbLf1MViTZsjPQWoZT/nV71Il8Fi0+2U5nhw+uxbgugdrY
	TEo982DMkF/Il8A1EnriO4+todAUd6whB1nYH67segihRLsJE8be6LS0izUhzFRzq9S9
	UEQhZg+f8H73CGwUYyodZyy7oAsNbjA+1lbxs=
MIME-Version: 1.0
Sender: amdragon@gmail.com
In-Reply-To: <AANLkTi=pPgcPXUN_XTXa0gAkbTR_OF4XxCP-d4-Be2pt@mail.gmail.com>
References: <87fwsetdin.fsf@kepler.schwinge.homeip.net>
	<8762taxk9y.fsf@algae.riseup.net>
	<87vd1a84qj.fsf@servo.finestructure.net>
	<AANLkTi=pPgcPXUN_XTXa0gAkbTR_OF4XxCP-d4-Be2pt@mail.gmail.com>
Date: Thu, 24 Feb 2011 01:59:37 -0500
Message-ID: <AANLkTi=KOx8aTJipkiArFVjEHE6zt_JypoASMiiAWBZ6@mail.gmail.com>
Subject: Re: notmuch's idea of concurrency / failing an invocation
From: Austin Clements <amdragon@mit.edu>
To: notmuch@notmuchmail.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Schwinge <thomas@schwinge.name>
Precedence: list

Now that I've split notmuch new up in to lots of small transactions, I
think the database locking issue is quite approachable.  Here's a
proposed locking protocol where a notmuch operation that wants to
modify the database blocks if there's another operation in progress
(instead of immediately failing like now), but indicates to the
in-progress operation that, when convenient, it should temporarily
abdicate the database.

Add a file to the .notmuch directory, say "lock", which we'll use for
fcntl locks (fcntl locks have nice properties, like automatic cleanup
on process exit and NFS compatibility).

To open the database for write,
1. Acquire an exclusive lock on byte 0 of the lock file (in blocking mode)
2. Acquire an exclusive lock on byte 1 of the lock file
3. Release the lock on byte 0
4. Open the Xapian database

When it's convenient to abdicate the lock, test if there are pending
operations by testing for a lock on byte 0 of the lock file using
F_GETLK.  If there's no lock on byte 0, just continue without
releasing the database.  Otherwise,
1. Close the Xapian database
2. Release the lock on byte 1
3. Re-lock and re-open the database.

In effect, this acts like one lock, since byte 1 is only ever acquired
while byte 0 is held, but splitting it across two locks like this lets
us "peek" at the waiter queue and see if someone is waiting.

Some possible extensions: We may want a timeout for how long to wait
for the lock (in case the lock holder gets wedged).  We could work
around DatabaseModified exceptions by having readers do essentially
the same thing as writers, but take the locks in shared mode.  Readers
wouldn't proceed in parallel with writers, but long-running writers
would relinquish the lock, so this isn't so bad.  Finally, concurrent
notmuch new's should probably be serialized (instead of repeatedly
abdicating to each other), so it may make sense to have an additional
"notmuch new lock".

On Thu, Jan 27, 2011 at 5:20 PM, Austin Clements <amdragon@mit.edu> wrote:
> I'm looking into breaking notmuch new up into small transactions. =A0It
> wouldn't be much a leap from there to simply close and reopen the databas=
e
> between transactions if another task wants to use it, which would release
> the lock and let the queued notmuch task have the database for a bit. =A0=
It
> seems silly to have a daemon when all of notmuch's state is already on di=
sk
> and queue on a lock is as good as a queue in a daemon, but without the
> accompanying architectural=A0shenanigans.