Re: 0.3 and async pre-fetch

[Sudish Joseph <sudish@mindspring.com>]

In article <w8s91bx3czp.fsf@hrym.ifi.uio.no>,
Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Sudish Joseph <sudish@mindspring.com> 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