From: Mike Kelly <pioto@pioto.org>
Subject: Re: notmuch's idea of concurrency / failing an invocation
To: notmuch@notmuchmail.org
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>
	<87fwsdobpy.fsf@yoom.home.cworth.org>
	<877hdps6og.fsf@kepler.schwinge.homeip.net>
In-Reply-To: <877hdps6og.fsf@kepler.schwinge.homeip.net>
MIME-Version: 1.0
Date: Fri, 28 Jan 2011 15:36:15 +0000
Message-Id: <1296228975-ner-3626@everglades>
Content-Type: text/plain
Precedence: list

On Fri, 28 Jan 2011 10:45:19 +0100, Thomas Schwinge <thomas@schwinge.name> wrote:
> > It would definitely be nice to avoid the complexity inherent in having a
> > daemon, but how do you imagine "queue on a lock" to work? We don't have
> > anything like that in place now.
>
> I suppose what he means is trying to get the lock, and if that fails wait
> a bit / wait until it is available again.
>
> Actually, as a next step, wouldn't it also be possible to add some
> heuristic to avoid ``notmuch new'' (being a low-priority task) blocking
> some interactive user (UI; high-priority task)?  But we can pursue such
> schemes as soon as the basic infrastructure is in place.

Couldn't we pretty much get the desired behavior by using flock(2)?
Basically, take out a LOCK_EX when we need to write, and a LOCK_SH when
we only need to read. Using the blocking form, things should pretty much
just queue up and take their turn, right?

I'm not familiar with Xapian, but if it doesn't give us something we
could use this sort of locking on, couldn't we just add some
/path/to/mail/.notmuch.lock file that we open to hold a lock on?

We already have to specify if we want a read-only or read-write database
handle in notmuch_database_open, so it seems like it'd be easy enough to
hook in there.

-- 
Mike Kelly