From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/7445 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: Re: 0.3 and async pre-fetch Date: 02 Aug 1996 20:35:18 -0400 Sender: sj@mindspring.com Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035147758 7264 80.91.224.250 (20 Oct 2002 21:02:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:02:38 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.5/8.6.9) with SMTP id RAA07480 for ; Fri, 2 Aug 1996 17:49:25 -0700 Original-Received: from atreides.erehwon.org (sj@user-168-121-167-78.dialup.mindspring.com [168.121.167.78]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 3 Aug 1996 02:30:58 +0200 Original-Received: (from sj@localhost) by atreides.erehwon.org (8.7.5/8.7.3) id UAA00439; Fri, 2 Aug 1996 20:35:19 -0400 Original-To: ding@ifi.uio.no In-Reply-To: Lars Magne Ingebrigtsen's message of 02 Aug 1996 19:35:54 +0200 Original-Lines: 49 X-Mailer: Red Gnus v0.4/XEmacs 19.14 Xref: main.gmane.org gmane.emacs.gnus.general:7445 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:7445 In article , Lars Magne Ingebrigtsen writes: > Sudish Joseph writes: >> I'm curious, why isn't anyone else reporting this? Is it that the >> bug is only visible over a slow connect? Has anyone else seen this? > There was a missing `(goto-char (point-max))' somewhere. The prefetch > seems to work ok in 0.4. Nope. I'm still seeing this in 0.4. The problem remains the same as what my patch tried to address (not very well, the problem lies in nntp-process-filter, fixing the generated callback is a workaround). I believe I've finally understood why this is happening: it has nothing to do with o/p arriving too quickly as I first suggested. (Rather stupidly, considering my PPP link :-) Here's the essence: nntp-process-filter should *never* use re-search-backward to identify the end of a command's output. And here's my usual verbiage: Emacs cannot make any guarantees about the string passed to any process filter. When the filter runs, the stack might have passed back a buffer containing the results of two separate commands -- the stack is driven by TCP timers and buffers. The reason I see the problem more often than any of you is because my link is slower from home -- there's a large amount of data waiting in TCP buffers on the nntp server. My link is running at full capacity (a whopping 31.2Kbs) and therefore the buffers being passed to nntp-process-filter will quite often contain the results of multiple commands. Conversely, those sitting on 10BaseT or better will rarely send out commands faster than the network can respond -- timeouts in the stack will pass those buffers back to you before your next command goes out or close enough to make no difference. Basically, the process filter should save the place the last o/p passed back to gnus-async ended at across invocations and use re-search-forward from that marker (the current stuff is neat in that it avoids saving that state, but I think that won't work). Sorta like I was doing in my patch (in the wrong place). I'm quite certain this will fix it. I'll code this tomorrow, if I get the time. -Sudish