From: Daniel Schoepe <daniel@schoepe.org>
To: James Vasile <james@hackervisions.org>, notmuch@notmuchmail.org
Subject: Re: [notmuch] [PATCH] Calls to notmuch get queued and executed
	asynchronously.
In-Reply-To: <87vddnlxos.wl%james@hackervisions.org>
References: <87vddnlxos.wl%james@hackervisions.org>
User-Agent: Notmuch/0.9-19-ga25c9a0 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-pc-linux-gnu)
Date: Fri, 21 Oct 2011 22:50:48 +0200
Message-ID: <87wrbykr13.fsf@gilead.invalid>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=

On Tue, 23 Feb 2010 11:32:51 -0500, James Vasile <james@hackervisions.org> wrote:
> Added notmuch-enqueue-asynch to replace calls to
> notmuch-call-notmuch-process.  Calls to notmuch are then queued and
> executed asynchronously.  If the db is busy and we get an error saying
> it was locked, keep trying until the db is no longer busy.  Errors go
> in a buffer as per usual.

I discovered this patch a while ago and it almost applies cleanly (the
conflicts are easy to fix though) and it has made the emacs UI for
notmuch _much_ more responsive and enjoyable for me. As discussed on
IRC, issues such as where to handle retries in case the database is
locked should probably be handled in the notmuch binary instead of each
UI.

I am however unaware of any patches to accomplish that and with the pace
of development / patch reviews the way it is at the moment, this patch
is a really helpful stop-gap (performing calls to notmuch asynchronously
is useful independently of where concurrency issues are handled though)
for me. If someone else agrees, I can fix the conflicts for this patch
and send the revised version to the list.

Cheers,
Daniel

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJOodsoAAoJEIaTAtce+Z+JfcUQAKRAClcxOAvAU3c2tEGNXNwf
DRvbttxYt+YtoGaBNwoyNRfHjg0elwGSVGd860ApbL4LC0coYADGOd0o41uXHLgJ
Zx0S/7MYwVZ+bh+0mlZ67wIGvvF9rqEkUmjoOCrAGIneBuSstLFTEsOVUL9+4rLX
qPGhhs6uTr0WWUHoSJwTlKeB8UruUORdTySyiMnjnRgUmkLrPEa1CIDatFAl/rSv
+CQZd1nZv7brZKrgPlJotb5S8bkHsceFmg699XwnvaEGegyuDvl8Etx6wjypVOZg
wTPysTZqmAn66P1Stpfdk8A0W+zXxRh2m7VcGi6rRtWKjaxEvtuxDCrxxR6HQFal
6mkda6hRVCIGxf7CFeL5Qnjh9HFjO+2oMQcYZfsLikmZ9ymN41CB+W2Yd36LB8LY
1b2wxKTMjmT3iXfmQOxfuJkeXr9zvGk/UuxEhxt+P4nePLU3oDGYhpHeoaY5Ih0G
6yFxzgh91lE/VEvJga4Jt/O6Po0j3eJ9jgvsmk4oyZT8rfW7HlYv5cBQIcfI2urq
jfIypf8H5BCp3zEYdiC43KELmd7tGlaUz36Zo6inIBukA5DiOJLbcMTB48taSVQ0
6dv9ntdIjNBrP1wmoEFCyoQVCE3mkGoN2ReBeh5ElfkebWO/nFQ04eblCTTQOtrf
MEBp78DNobSEFos4fkfl
=1ogW
-----END PGP SIGNATURE-----
--=-=-=--