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.  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.<br>
<br><div class="gmail_quote">On Thu, Jan 27, 2011 at 3:35 PM, Jameson Rollins <span dir="ltr"><<a href="mailto:jrollins@finestructure.net">jrollins@finestructure.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, 27 Jan 2011 13:40:25 -0500, micah anderson <<a href="mailto:micah@riseup.net">micah@riseup.net</a>> wrote:<br>
> Due to my harddisk in my laptop being slow (5400RPM), my notmuch<br>
> database growing, and perhaps some fragmentation somewhere, this has<br>
> become *incredibly* annoying for me. I am checking email every 30<br>
> minutes, and I'm nicing and ionicing the processes so I can use my<br>
> machine, but while those processes are running, I'm effectively locked<br>
> out of a good portion of my email.<br>
<br>
</div>I also have a very slow disk, but this is very rarely a problem for me.<br>
I retrieve mail every 10 minutes, and the corresponding notmuch new<br>
usually takes a minute or so.  I really haven't found it to be much of a<br>
bother to just wait it out.<br>
<br>
One of the suggested ways to develop around this problem would be a<br>
notmuch daemon that would queue database modification requests.  I don't<br>
think anyone has been working on this yet, but if this is a big problem<br>
for you guys, you might start looking into putting one together.<br>
<br>
jamie.</blockquote></div>