On Thu, 27 Jan 2011 17:20:21 -0500, Austin Clements <amdra...@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.wo...@intel.com
pgpoj9kgctg0O.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
