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>
