On Fri, Jan 28, 2011 at 10:36 AM, Mike Kelly <pioto@pioto.org> wrote:

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?

Yes, exactly. All of this. Unfortunately, Xapian doesn't expose the ability to block on the lock (see the fcntl call in backends/flint_lock.cc, which is hard-coded to the non-blocking F_SETLK instead of F_SETLKW), so we'd either need a new Xapian option, or we would just have to wrap our own flock/fcntl lock around things as you suggest.