--- /dev/null
+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