Re: notmuch's idea of concurrency / failing an invocation

Subject: Re: notmuch's idea of concurrency / failing an invocation

Date: Fri, 28 Jan 2011 15:10:01 +1000

To: Austin Clements, Jameson Rollins

Cc: notmuch@notmuchmail.org, Thomas Schwinge

From: Carl Worth


On Thu, 27 Jan 2011 17:20:21 -0500, Austin Clements <amdragon@mit.edu> wrote:
> I'm looking into breaking notmuch new up into small transactions.  It
> wouldn't be much a leap from there to simply close and reopen the database
> between transactions if another task wants to use it, which would release
> the lock and let the queued notmuch task have the database for a bit.

That sounds like something very useful to pursue. Please continue!

> It seems silly to have a daemon when all of notmuch's state is already on disk
> and queue on a lock is as good as a queue in a daemon, but without the
> accompanying architectural shenanigans.

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.

Another advantage that can happen with queueing (wherever it occurs) is
to allow a client to be very responsive without waiting for an operation
to complete. Though that can of course be band if the operation isn't
reliably committed.

-Carl

-- 
carl.d.worth@intel.com
part-000.sig (application/pgp-signature)

Thread: