28/b42be4fefcf62d9cb1ff714a5a2df5a92942b8

   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 86C2B431FB6\r
   6         for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 08:50:10 -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=unavailable\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 wlToYhUUJdzS for <notmuch@notmuchmail.org>;\r
  17         Fri, 28 Jan 2011 08:50:10 -0800 (PST)\r
  18 Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com\r
  19         [209.85.216.181]) (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 3D579431FB5\r
  22         for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 08:50:10 -0800 (PST)\r
  23 Received: by qyk12 with SMTP id 12so3847842qyk.5\r
  24         for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 08:50:07 -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=LWh/YPZ3sZgb09PbtoIAIx20cRDOtthuwZx6kV5uadE=;\r
  29         b=O14s8K51mdGbAh4cL+dDNyRol7NC5pQtTQ/gzw0RsKyjosspm2zDqqRKLTp7wWrm+9\r
  30         yMb1+z/0PVR1VMAf8kXVXXykZW7sk5kr9ttCp9tpS5asrQcEe3pAf7dGJs/NB6TKAULx\r
  31         77Uf0foxxV1NYlCLWPEP8b6aIQ12/ofbWgx9E=\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=GooC66BodM9j93SQvezKhlWQLUTsn/gQAk+tOd3QHAET10q72D+LMQ7+tXHFgRq2gl\r
  36         grDzJxiM7YoJdIeSCiGLF1V05Mj4PC5lBEBjenNPrVsImJEhPiNSm4eJrtmZJ3ZwXsG7\r
  37         PEHwCl8l7bq5tT344PPiyf3HOUPz8y/eGGPrs=\r
  38 MIME-Version: 1.0\r
  39 Received: by 10.229.220.81 with SMTP id hx17mr1097268qcb.116.1296233407012;\r
  40         Fri, 28 Jan 2011 08:50:07 -0800 (PST)\r
  41 Sender: amdragon@gmail.com\r
  42 Received: by 10.229.97.143 with HTTP; Fri, 28 Jan 2011 08:50:06 -0800 (PST)\r
  43 In-Reply-To: <877hdps6og.fsf@kepler.schwinge.homeip.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         <AANLkTi=pPgcPXUN_XTXa0gAkbTR_OF4XxCP-d4-Be2pt@mail.gmail.com>\r
  48         <87fwsdobpy.fsf@yoom.home.cworth.org>\r
  49         <877hdps6og.fsf@kepler.schwinge.homeip.net>\r
  50 Date: Fri, 28 Jan 2011 11:50:06 -0500\r
  51 X-Google-Sender-Auth: 78sJDERwTTQySqnTPb7GeuBDKhg\r
  52 Message-ID: <AANLkTinUhmcNKH6eFfcfygrc3XcVZoeDzVMFBSUi4LRQ@mail.gmail.com>\r
  53 Subject: Re: notmuch's idea of concurrency / failing an invocation\r
  54 From: Austin Clements <amdragon@mit.edu>\r
  55 To: Thomas Schwinge <thomas@schwinge.name>\r
  56 Content-Type: multipart/alternative; boundary=00163630eb23c56d45049aeadbb9\r
  57 Cc: notmuch@notmuchmail.org\r
  58 X-BeenThere: notmuch@notmuchmail.org\r
  59 X-Mailman-Version: 2.1.13\r
  60 Precedence: list\r
  61 List-Id: "Use and development of the notmuch mail system."\r
  62         <notmuch.notmuchmail.org>\r
  63 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  64         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  65 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  66 List-Post: <mailto:notmuch@notmuchmail.org>\r
  67 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  68 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  69         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  70 X-List-Received-Date: Fri, 28 Jan 2011 16:50:10 -0000\r
  71 \r
  72 --00163630eb23c56d45049aeadbb9\r
  73 Content-Type: text/plain; charset=ISO-8859-1\r
  74 \r
  75 On Fri, Jan 28, 2011 at 4:45 AM, Thomas Schwinge <thomas@schwinge.name>wrote:\r
  76 \r
  77 > On Fri, 28 Jan 2011 15:10:01 +1000, Carl Worth <cworth@cworth.org> wrote:\r
  78 > > On Thu, 27 Jan 2011 17:20:21 -0500, Austin Clements <amdragon@mit.edu>\r
  79 > wrote:\r
  80 > > > I'm looking into breaking notmuch new up into small transactions.  It\r
  81 > > > wouldn't be much a leap from there to simply close and reopen the\r
  82 > database\r
  83 > > > between transactions if another task wants to use it, which would\r
  84 > release\r
  85 > > > the lock and let the queued notmuch task have the database for a bit.\r
  86 > >\r
  87 > > That sounds like something very useful to pursue. Please continue!\r
  88 >\r
  89 > Ack!  And actually -- I just wondered about that: what happens if\r
  90 > ``notmuch new'' has executed notmuch_database_add_message for a new\r
  91 > message M, but then is killed before adding any tags and finishing up\r
  92 > (and supposing that the DB isn't in an invalid state now).  This process\r
  93 > of adding M to the DB and applying any tags isn't one single transaction\r
  94 > currently, right?  (And this is exactly what you're working on\r
  95 > chainging?)  Am I right that what currently happens is that upon the next\r
  96 > ``notmuch new'' run, notmuch will not reconsider M (given that it already\r
  97 > is present in the DB), but continue with the next messages -- thus\r
  98 > leaving M without any tags?  This isn't a very likely scenario, but still\r
  99 > a possible one.\r
 100 \r
 101 \r
 102 There are quite a few bugs like this.  In fact, last night I added a test\r
 103 that interrupts notmuch new (for real, not SIGINT) after every database\r
 104 write, and on each interrupted database snapshot, re-runs notmuch new to\r
 105 completion, then checks that the database winds up in the correct state.\r
 106  There are dozens of interruption points where it doesn't, many of which are\r
 107 permanent, even if you force notmuch new to rescan the maildir.\r
 108 \r
 109 > Another advantage that can happen with queueing (wherever it occurs) is\r
 110 > > to allow a client to be very responsive without waiting for an operation\r
 111 > > to complete. Though that can of course be band if the operation isn't\r
 112 > > reliably committed.\r
 113 >\r
 114 > (Obviously this can only work as long as we don't immediatelly need the\r
 115 > operation's result; think ``notmuch show''.)\r
 116 >\r
 117 > So, if the DB has the functionality to internally queue and immediatelly\r
 118 > acknowledge transactions, and only later (reliably) commit them, wouldn't\r
 119 > that be fine indeed?  For example, ``notmuch tag'' then wouldn't have to\r
 120 > wait for the DB to be writable.  (And note that I have no idea whether\r
 121 > Xapian supports such things.)  But on the other hand we would like to\r
 122 > immediatelly display the requested change in the UI, right?\r
 123 >\r
 124 \r
 125 This would be fantastic, if the client could indicate the difference between\r
 126 a "pending" change and a "committed" change as you suggest below.  I don't\r
 127 think having the database lie about its commit state is the right way to do\r
 128 this, though (nor should the client lie about this, thus the "pending"\r
 129 display).  A better way would be for the client to update the display to\r
 130 "pending", start the notmuch operation asynchronously, have the notmuch\r
 131 operation block and queue up on the database lock, then have the client\r
 132 update the display to "committed" when the asynchronous operation returns.\r
 133  No weird database operations or transactional semantics and the client side\r
 134 is fairly straightforward.\r
 135 \r
 136 --00163630eb23c56d45049aeadbb9\r
 137 Content-Type: text/html; charset=ISO-8859-1\r
 138 Content-Transfer-Encoding: quoted-printable\r
 139 \r
 140 <div class=3D"gmail_quote">On Fri, Jan 28, 2011 at 4:45 AM, Thomas Schwinge=\r
 141  <span dir=3D"ltr">&lt;<a href=3D"mailto:thomas@schwinge.name">thomas@schwi=\r
 142 nge.name</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=\r
 143 =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">\r
 144 <div class=3D"im">On Fri, 28 Jan 2011 15:10:01 +1000, Carl Worth &lt;<a hre=\r
 145 f=3D"mailto:cworth@cworth.org">cworth@cworth.org</a>&gt; wrote:<br>\r
 146 &gt; On Thu, 27 Jan 2011 17:20:21 -0500, Austin Clements &lt;<a href=3D"mai=\r
 147 lto:amdragon@mit.edu">amdragon@mit.edu</a>&gt; wrote:<br>\r
 148 &gt; &gt; I&#39;m looking into breaking notmuch new up into small transacti=\r
 149 ons. =A0It<br>\r
 150 &gt; &gt; wouldn&#39;t be much a leap from there to simply close and reopen=\r
 151  the database<br>\r
 152 &gt; &gt; between transactions if another task wants to use it, which would=\r
 153  release<br>\r
 154 &gt; &gt; the lock and let the queued notmuch task have the database for a =\r
 155 bit.<br>\r
 156 &gt;<br>\r
 157 &gt; That sounds like something very useful to pursue. Please continue!<br>\r
 158 <br>\r
 159 </div>Ack! =A0And actually -- I just wondered about that: what happens if<b=\r
 160 r>\r
 161 ``notmuch new&#39;&#39; has executed notmuch_database_add_message for a new=\r
 162 <br>\r
 163 message M, but then is killed before adding any tags and finishing up<br>\r
 164 (and supposing that the DB isn&#39;t in an invalid state now). =A0This proc=\r
 165 ess<br>\r
 166 of adding M to the DB and applying any tags isn&#39;t one single transactio=\r
 167 n<br>\r
 168 currently, right? =A0(And this is exactly what you&#39;re working on<br>\r
 169 chainging?) =A0Am I right that what currently happens is that upon the next=\r
 170 <br>\r
 171 ``notmuch new&#39;&#39; run, notmuch will not reconsider M (given that it a=\r
 172 lready<br>\r
 173 is present in the DB), but continue with the next messages -- thus<br>\r
 174 leaving M without any tags? =A0This isn&#39;t a very likely scenario, but s=\r
 175 till<br>\r
 176 a possible one.</blockquote><div>=A0</div><div>There are quite a few bugs l=\r
 177 ike this. =A0In fact, last night I added a test that interrupts notmuch new=\r
 178 =A0(for real, not SIGINT)=A0after every database write, and on each interru=\r
 179 pted database snapshot, re-runs notmuch new to completion, then checks that=\r
 180  the database winds up in the correct state. =A0There are dozens of interru=\r
 181 ption points where it doesn&#39;t, many of which are permanent, even if you=\r
 182  force notmuch new to rescan the maildir.</div>\r
 183 <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><d=\r
 184 iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=\r
 185 order-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">&gt; Another=\r
 186  advantage that can happen with queueing (wherever it occurs) is</div>\r
 187 <div class=3D"im">\r
 188 &gt; to allow a client to be very responsive without waiting for an operati=\r
 189 on<br>\r
 190 &gt; to complete. Though that can of course be band if the operation isn&#3=\r
 191 9;t<br>\r
 192 &gt; reliably committed.<br>\r
 193 <br>\r
 194 </div>(Obviously this can only work as long as we don&#39;t immediatelly ne=\r
 195 ed the<br>\r
 196 operation&#39;s result; think ``notmuch show&#39;&#39;.)<br>\r
 197 <br>\r
 198 So, if the DB has the functionality to internally queue and immediatelly<br=\r
 199 >\r
 200 acknowledge transactions, and only later (reliably) commit them, wouldn&#39=\r
 201 ;t<br>\r
 202 that be fine indeed? =A0For example, ``notmuch tag&#39;&#39; then wouldn&#3=\r
 203 9;t have to<br>\r
 204 wait for the DB to be writable. =A0(And note that I have no idea whether<br=\r
 205 >\r
 206 Xapian supports such things.) =A0But on the other hand we would like to<br>\r
 207 immediatelly display the requested change in the UI, right?<br></blockquote=\r
 208 ><div><br></div><div>This would be fantastic, if the client could indicate =\r
 209 the difference between a &quot;pending&quot; change and a &quot;committed&q=\r
 210 uot; change as you suggest below. =A0I don&#39;t think having the database =\r
 211 lie about its commit state is the right way to do this, though (nor should =\r
 212 the client lie about this, thus the &quot;pending&quot; display). =A0A bett=\r
 213 er way would be for the client to update the display to &quot;pending&quot;=\r
 214 , start the notmuch operation asynchronously, have the notmuch operation bl=\r
 215 ock and queue up on the database lock, then have the client update the disp=\r
 216 lay to &quot;committed&quot; when the asynchronous operation returns. =A0No=\r
 217  weird database operations or transactional semantics and the client side i=\r
 218 s fairly straightforward.</div>\r
 219 <div><br></div></div>\r
 220 \r
 221 --00163630eb23c56d45049aeadbb9--\r