<div class="gmail_quote">On Fri, Jan 28, 2011 at 10:36 AM, Mike Kelly <span dir="ltr"><<a href="mailto:pioto@pioto.org">pioto@pioto.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, 28 Jan 2011 10:45:19 +0100, Thomas Schwinge <<a href="mailto:thomas@schwinge.name">thomas@schwinge.name</a>> wrote:<br>
> > It would definitely be nice to avoid the complexity inherent in having a<br>
> > daemon, but how do you imagine "queue on a lock" to work? We don't have<br>
> > anything like that in place now.<br>
><br>
> I suppose what he means is trying to get the lock, and if that fails wait<br>
> a bit / wait until it is available again.<br>
><br>
> Actually, as a next step, wouldn't it also be possible to add some<br>
> heuristic to avoid ``notmuch new'' (being a low-priority task) blocking<br>
> some interactive user (UI; high-priority task)?  But we can pursue such<br>
> schemes as soon as the basic infrastructure is in place.<br>
<br>
</div>Couldn't we pretty much get the desired behavior by using flock(2)?<br>
Basically, take out a LOCK_EX when we need to write, and a LOCK_SH when<br>
we only need to read. Using the blocking form, things should pretty much<br>
just queue up and take their turn, right?<br>
<br>
I'm not familiar with Xapian, but if it doesn't give us something we<br>
could use this sort of locking on, couldn't we just add some<br>
/path/to/mail/.notmuch.lock file that we open to hold a lock on?<br></blockquote><div><br></div><div>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.</div>
<div><br></div></div>