On Fri, Jan 28, 2011 at 10:36 AM, Mike Kelly wrote: > On Fri, 28 Jan 2011 10:45:19 +0100, Thomas Schwinge > 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.