Re: [BUG] Emacs UI dropping every 25th line, roughly
authorThomas Schwinge <thomas@schwinge.name>
Wed, 2 Feb 2011 16:12:16 +0000 (17:12 +0100)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:37:51 +0000 (09:37 -0800)
d3/2c2b9c5d08faf2510ec9cbfe786cbe0939e7e3 [new file with mode: 0644]

diff --git a/d3/2c2b9c5d08faf2510ec9cbfe786cbe0939e7e3 b/d3/2c2b9c5d08faf2510ec9cbfe786cbe0939e7e3
new file mode 100644 (file)
index 0000000..5c5702c
--- /dev/null
@@ -0,0 +1,139 @@
+Return-Path: <thomas@schwinge.name>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 1DC20431FB6\r
+       for <notmuch@notmuchmail.org>; Wed,  2 Feb 2011 08:12:36 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_NONE=-0.0001] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id ZfyjmOcJ06Vf for <notmuch@notmuchmail.org>;\r
+       Wed,  2 Feb 2011 08:12:35 -0800 (PST)\r
+Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de\r
+       [80.67.31.36])\r
+       by olra.theworths.org (Postfix) with ESMTP id D06AE431FB5\r
+       for <notmuch@notmuchmail.org>; Wed,  2 Feb 2011 08:12:34 -0800 (PST)\r
+Received: from [87.180.46.33] (helo=stokes.schwinge.homeip.net)\r
+       by smtprelay02.ispgateway.de with esmtpa (Exim 4.68)\r
+       (envelope-from <thomas@schwinge.name>) id 1PkfJo-00079S-3A\r
+       for notmuch@notmuchmail.org; Wed, 02 Feb 2011 17:12:32 +0100\r
+Received: (qmail 2062 invoked from network); 2 Feb 2011 16:12:21 -0000\r
+Received: from kepler.schwinge.homeip.net (192.168.111.7)\r
+       by stokes.schwinge.homeip.net with QMQP; 2 Feb 2011 16:12:21 -0000\r
+Received: (nullmailer pid 8428 invoked by uid 1000);\r
+       Wed, 02 Feb 2011 16:12:21 -0000\r
+From: Thomas Schwinge <thomas@schwinge.name>\r
+To: notmuch@notmuchmail.org\r
+Subject: Re: [BUG] Emacs UI dropping every 25th line, roughly\r
+In-Reply-To: <87tygqm7g4.fsf@kepler.schwinge.homeip.net>\r
+References: <87tygqm7g4.fsf@kepler.schwinge.homeip.net>\r
+User-Agent: Notmuch/0.5-33-g665f77b (http://notmuchmail.org) Emacs/23.2.1\r
+       (i486-pc-linux-gnu)\r
+Date: Wed, 02 Feb 2011 17:12:16 +0100\r
+Message-ID: <87zkqeiffj.fsf@kepler.schwinge.homeip.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-Df-Sender: thomas@schwinge.name\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 02 Feb 2011 16:12:36 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+Hallo!\r
+\r
+On Sun, 30 Jan 2011 22:02:03 +0100, I wrote:\r
+> That is, roughly every 25th line is dropped in the Emacs notmuch-search\r
+> buffer!  (Via setting notmuch-command to a shell script, I intercepted\r
+> the notmuch / emacs pipeline with tee, and found that what comes out of\r
+> ``notmuch | tee'' is still sane, so I'm fairly sure it's an Emacs /\r
+> notmuch elisp code issue.)\r
+>=20\r
+> And, 25 times the medium length of a ``notmuch search [...]'' output line\r
+> is... 4 KiB, the standard page size.  Is this ``just'' a problem in the\r
+> notmuch elisp code, or is Emacs doing something awful with (wild\r
+> speculation...) short reads on buffer page boundaries (or whatever else)?\r
+\r
+I began to analyze this.  Here is a dump of my steps.\r
+\r
+I used strace on the (already running) Emacs process.  strace would log\r
+to several files: one for the main (Emacs) process, and a new one for\r
+each forked process.  I can see that a ``notmuch search [...]'' process\r
+is fork()ed / exec()uted.  It does a lot of read()ing from the DB, and\r
+write()s out the results record by record (which in our case means line\r
+by line).  Up to the point where I examined, there have been no short\r
+writes.  The log:\r
+\r
+    [some write()s for the first two dozen search results]\r
+    16:26:54.143464 write(1, "thread:00000000000006c7   2009-12-16 [2/2] Th=\r
+omas Schwinge; [subject] ([flags])\n", 135) =3D 135\r
+    [...]\r
+    16:26:54.266866 write(1, "thread:0000000000000ac4   2009-12-16 [1/1] js=\r
+m28@sourceware.org; [subject] ([flags])\n", 181) =3D 181\r
+\r
+At this / in the middle of this point, the 4 KiB size is hit.  After\r
+accumulating some more (notice the 3.6 seconds delay), Emacs read()s the\r
+first chunk (line breaks inserted for clarity):\r
+\r
+    16:26:57.928798 read(8, "[first two dozen results]"\r
+                            "thread:00000000000006c7   2009-12-16 [2/2] Tho=\r
+mas Schwinge; [subject] ([flags])\n"\r
+                            "t", 4096) =3D 4095\r
+\r
+The last result line is obviously incomplete, only the `t' so far.\r
+\r
+There is more to be read, so Emacs quickly goes on with the next chunk:\r
+\r
+    16:26:57.966247 read(8, "hread:0000000000000ac4   2009-12-16 [1/1] jsm2=\r
+8@sourceware.org; [subject] ([flags])\n"\r
+                            "[more results]", 4096) =3D 4095\r
+\r
+That's the remainder of the partial line, plus further results.  This is\r
+all fine.  It's now Emacs' job to re-assemble the two partial lines\r
+(thread ac4).  I note that indeed this search result is missing in the\r
+notmuch-search buffer.\r
+\r
+(By the way, I wonder why read() returns 4095 bytes instead of 4096?)\r
+\r
+I'll next move on to debugging what actually appears at the elisp layer.\r
+I somehow don't think the Emacs core is faulty; probably rather our\r
+asynchronous results presentation layer handles partial lines\r
+incorrectly?  More to come later.\r
+\r
+\r
+Gr=C3=BC=C3=9Fe,\r
+ Thomas\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iQEcBAEBAgAGBQJNSYJgAAoJEGe3hdm9kOiiqm4H/ReVsJ9ND/UH+IMKkvMvyzsJ\r
+DJGg8hjrzfmFJmIKyC8I0+JHtHBGQtExgEy4GfkTIKkt1/7n/fVm0JVOG0p3yJY8\r
+mdagH7Cf3nI34zPn5vfZjtD0rn8EaezKbus67oO+3NGbjwgXEwg6K6RUdQSOhOq/\r
+V8giOpUwfjf48U2xVsg6+09jQnRf51LylbC2NoKEQyc/shDmsHV2rbrf/Ml6Plhp\r
+/O8AvhWNHoYx4LpUDvPY4U0bjEp5/rPPPIOJY/VcgDXRztpMABoGJsnQnu684k06\r
+kzWi8yn7BHzjL9ZjSclVm8/J/v168nW1TtOJ5nxKtfaSYP4l7J0AX1ENEiZV8Xs=\r
+=BH3d\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r