notmuch's idea of concurrency / failing an invocation

[Carl Worth]

On Thu, 27 Jan 2011 17:20:21 -0500, Austin Clements <amdragon at 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 at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110128/5d7df2b8/attachment-0001.pgp>