f5/4e056f0bd827aa8aeef2d459af5d81dcd92861

   1 Return-Path: <amdragon@gmail.com>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id EDB96431FD0\r
   6         for <notmuch@notmuchmail.org>; Thu, 27 Jan 2011 14:20:23 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.698\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
  13         HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id AXVxuOUHUx1R for <notmuch@notmuchmail.org>;\r
  17         Thu, 27 Jan 2011 14:20:22 -0800 (PST)\r
  18 Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com\r
  19         [209.85.216.53]) (using TLSv1 with cipher RC4-MD5 (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 1F750431FB5\r
  22         for <notmuch@notmuchmail.org>; Thu, 27 Jan 2011 14:20:22 -0800 (PST)\r
  23 Received: by qwe5 with SMTP id 5so2792053qwe.26\r
  24         for <notmuch@notmuchmail.org>; Thu, 27 Jan 2011 14:20:21 -0800 (PST)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=domainkey-signature:mime-version:sender:in-reply-to:references:date\r
  27         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;\r
  28         bh=wZJh0VSCs3Bs1cTR5EvBJaIvVTijx+qUUmpPc6ILz3g=;\r
  29         b=WzWXSUpoks7I0kAR+nQKnDSaz2SBVdB2FHmT2rRDM143zVhq9YJUR2usRemLjLAOjL\r
  30         4qdZ8WrYSWM9gUBzpkx88TvqNQcQShzmInCZvqmaIonlES5c8es2DkiLo4IQ5+QcvLhT\r
  31         SPCrLg7pqxkbVWGPpp0agsGBl9ZOzPr9RBE3I=\r
  32 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  33         h=mime-version:sender:in-reply-to:references:date\r
  34         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;\r
  35         b=Axm6Z5hfmpOxbxUQqiSgd63NsLC0XIGrl51GiC6LWVfsNMChPWf7sQptyKP/E54XDG\r
  36         fnMduPQFNGBLnRNsdNsC1jEiEylPxhGh9Ud1MX18ttk6bGFtLfnuwbaMqh0RgKgruGyY\r
  37         u4l2vN/+XUU5peFMpHeHe+RO31BIQP7MAtyzU=\r
  38 MIME-Version: 1.0\r
  39 Received: by 10.229.240.85 with SMTP id kz21mr2022742qcb.2.1296166821212; Thu,\r
  40         27 Jan 2011 14:20:21 -0800 (PST)\r
  41 Sender: amdragon@gmail.com\r
  42 Received: by 10.229.97.143 with HTTP; Thu, 27 Jan 2011 14:20:21 -0800 (PST)\r
  43 In-Reply-To: <87vd1a84qj.fsf@servo.finestructure.net>\r
  44 References: <87fwsetdin.fsf@kepler.schwinge.homeip.net>\r
  45         <8762taxk9y.fsf@algae.riseup.net>\r
  46         <87vd1a84qj.fsf@servo.finestructure.net>\r
  47 Date: Thu, 27 Jan 2011 17:20:21 -0500\r
  48 X-Google-Sender-Auth: _mfErxMh_hNNCMnTa7jFiM6oS5c\r
  49 Message-ID: <AANLkTi=pPgcPXUN_XTXa0gAkbTR_OF4XxCP-d4-Be2pt@mail.gmail.com>\r
  50 Subject: Re: notmuch's idea of concurrency / failing an invocation\r
  51 From: Austin Clements <amdragon@mit.edu>\r
  52 To: Jameson Rollins <jrollins@finestructure.net>\r
  53 Content-Type: multipart/alternative; boundary=0016363101e5f2b320049adb5ab1\r
  54 Cc: notmuch@notmuchmail.org, Thomas Schwinge <thomas@schwinge.name>\r
  55 X-BeenThere: notmuch@notmuchmail.org\r
  56 X-Mailman-Version: 2.1.13\r
  57 Precedence: list\r
  58 List-Id: "Use and development of the notmuch mail system."\r
  59         <notmuch.notmuchmail.org>\r
  60 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  61         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  62 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  63 List-Post: <mailto:notmuch@notmuchmail.org>\r
  64 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  65 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  66         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  67 X-List-Received-Date: Thu, 27 Jan 2011 22:20:24 -0000\r
  68 \r
  69 --0016363101e5f2b320049adb5ab1\r
  70 Content-Type: text/plain; charset=ISO-8859-1\r
  71 \r
  72 I'm looking into breaking notmuch new up into small transactions.  It\r
  73 wouldn't be much a leap from there to simply close and reopen the database\r
  74 between transactions if another task wants to use it, which would release\r
  75 the lock and let the queued notmuch task have the database for a bit.  It\r
  76 seems silly to have a daemon when all of notmuch's state is already on disk\r
  77 and queue on a lock is as good as a queue in a daemon, but without the\r
  78 accompanying architectural shenanigans.\r
  79 \r
  80 On Thu, Jan 27, 2011 at 3:35 PM, Jameson Rollins <jrollins@finestructure.net\r
  81 > wrote:\r
  82 \r
  83 > On Thu, 27 Jan 2011 13:40:25 -0500, micah anderson <micah@riseup.net>\r
  84 > wrote:\r
  85 > > Due to my harddisk in my laptop being slow (5400RPM), my notmuch\r
  86 > > database growing, and perhaps some fragmentation somewhere, this has\r
  87 > > become *incredibly* annoying for me. I am checking email every 30\r
  88 > > minutes, and I'm nicing and ionicing the processes so I can use my\r
  89 > > machine, but while those processes are running, I'm effectively locked\r
  90 > > out of a good portion of my email.\r
  91 >\r
  92 > I also have a very slow disk, but this is very rarely a problem for me.\r
  93 > I retrieve mail every 10 minutes, and the corresponding notmuch new\r
  94 > usually takes a minute or so.  I really haven't found it to be much of a\r
  95 > bother to just wait it out.\r
  96 >\r
  97 > One of the suggested ways to develop around this problem would be a\r
  98 > notmuch daemon that would queue database modification requests.  I don't\r
  99 > think anyone has been working on this yet, but if this is a big problem\r
 100 > for you guys, you might start looking into putting one together.\r
 101 >\r
 102 > jamie.\r
 103 \r
 104 --0016363101e5f2b320049adb5ab1\r
 105 Content-Type: text/html; charset=ISO-8859-1\r
 106 Content-Transfer-Encoding: quoted-printable\r
 107 \r
 108 I&#39;m looking into breaking notmuch new up into small transactions. =A0It=\r
 109  wouldn&#39;t be much a leap from there to simply close and reopen the data=\r
 110 base between transactions if another task wants to use it, which would rele=\r
 111 ase the lock and let the queued notmuch task have the database for a bit. =\r
 112 =A0It seems silly to have a daemon when all of notmuch&#39;s state is alrea=\r
 113 dy on disk and queue on a lock is as good as a queue in a daemon, but witho=\r
 114 ut the accompanying architectural=A0shenanigans.<br>\r
 115 <br><div class=3D"gmail_quote">On Thu, Jan 27, 2011 at 3:35 PM, Jameson Rol=\r
 116 lins <span dir=3D"ltr">&lt;<a href=3D"mailto:jrollins@finestructure.net">jr=\r
 117 ollins@finestructure.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=\r
 118 l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=\r
 119 :1ex;">\r
 120 <div class=3D"im">On Thu, 27 Jan 2011 13:40:25 -0500, micah anderson &lt;<a=\r
 121  href=3D"mailto:micah@riseup.net">micah@riseup.net</a>&gt; wrote:<br>\r
 122 &gt; Due to my harddisk in my laptop being slow (5400RPM), my notmuch<br>\r
 123 &gt; database growing, and perhaps some fragmentation somewhere, this has<b=\r
 124 r>\r
 125 &gt; become *incredibly* annoying for me. I am checking email every 30<br>\r
 126 &gt; minutes, and I&#39;m nicing and ionicing the processes so I can use my=\r
 127 <br>\r
 128 &gt; machine, but while those processes are running, I&#39;m effectively lo=\r
 129 cked<br>\r
 130 &gt; out of a good portion of my email.<br>\r
 131 <br>\r
 132 </div>I also have a very slow disk, but this is very rarely a problem for m=\r
 133 e.<br>\r
 134 I retrieve mail every 10 minutes, and the corresponding notmuch new<br>\r
 135 usually takes a minute or so. =A0I really haven&#39;t found it to be much o=\r
 136 f a<br>\r
 137 bother to just wait it out.<br>\r
 138 <br>\r
 139 One of the suggested ways to develop around this problem would be a<br>\r
 140 notmuch daemon that would queue database modification requests. =A0I don&#3=\r
 141 9;t<br>\r
 142 think anyone has been working on this yet, but if this is a big problem<br>\r
 143 for you guys, you might start looking into putting one together.<br>\r
 144 <br>\r
 145 jamie.</blockquote></div>\r
 146 \r
 147 --0016363101e5f2b320049adb5ab1--\r