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=R09gMMvGatRWAXdZAG1BviYrq01YsSSfgepdiEFJJlqI1kBZP80nusKrL8SXFOms9I
	M6DbR3T3quhoqU6hXCTl4S3hcr23UvYyIpoZJ5traEIksBb/lJ9fY8xDBBvWS+QnvjHR
	Dd9Wm1N9gk4TBBG4Za+a+ATgU0cOuID4KMohA=
MIME-Version: 1.0
Sender: amdragon@gmail.com
In-Reply-To: <AANLkTim9FEEn6bpeAb1oHVScs4RGbK-UrFY+52ZKWv4E@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>
	<87fwsdobpy.fsf@yoom.home.cworth.org>
	<877hdps6og.fsf@kepler.schwinge.homeip.net>
	<1296228975-ner-3626@everglades>
	<AANLkTim9FEEn6bpeAb1oHVScs4RGbK-UrFY+52ZKWv4E@mail.gmail.com>
Date: Fri, 28 Jan 2011 13:17:18 -0500
Message-ID: <AANLkTi=jiVNAUsrjFd-Sw6FEFywMuUsVYetVo=R8fPDW@mail.gmail.com>
Subject: Re: notmuch's idea of concurrency / failing an invocation
From: Austin Clements <amdragon@mit.edu>
To: Mike Kelly <pioto@pioto.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

Actually, this is trivial to play with.  Here's a stop-gap wrapper
script for people having trouble with Xapian locking,

#!/bin/bash

NOTMUCH_BIN=3D"/path/to/notmuch"
MAIL_DIR=3D"/path/to/mailroot"

(
    case "$1" in
        setup|help)
            ;;
        search|show|count|reply|dump|search-tags|part)
            flock -s 200;;
        *)
            flock -x 200;;
    esac
    "$NOTMUCH_BIN" "$@" 200>&-
) 200>"$MAIL_DIR"/.notmuch/lock

On Fri, Jan 28, 2011 at 11:57 AM, Austin Clements <amdragon@mit.edu> wrote:
>
> 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.nam=
e> wrote:
>> > > It would definitely be nice to avoid the complexity inherent in havi=
ng a
>> > > daemon, but how do you imagine "queue on a lock" to work? We don't h=
ave
>> > > anything like that in place now.
>> >
>> > I suppose what he means is trying to get the lock, and if that fails w=
ait
>> > 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) blockin=
g
>> > some interactive user (UI; high-priority task)? =A0But we can pursue s=
uch
>> > 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. =A0All of this. =A0Unfortunately, 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.