Re: [ patch ] async stuff fix(?) (was Re: 0.3 and async pre-fetch)

[Sudish Joseph <sudish@mindspring.com>]

In article <x6wwzdwyau.fsf@eyesore.no>,
Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
>> discarded for every article prefetched currently), d) make it easier
>> to guarantee that responses are tagged with the correct group-article
>> id.

> It'd make it harder to guarantee anything, because things would then
> rely on variables that might have changed in the meantime.  

There's only one shared variable: the queue tracking group/article
pairs.  This variable has nice properties that make it easy to share.

a) It's a strict producer-consumer buffer with the very useful
property of being unbounded (we look at a finite subset of the buffer
at any given time, but that subset moves monotonically along the
unbounded buffer).  This means that the thornier of the two issues
requiring a lock in P-C problems is eliminated: we never have to check
for overflow.  This leaves underflow.

b) The producer (gnus-async-prefetch-article) always stays a fixed
number of items ahead of the consumer (*).  More importantly, the
producer stops producing at a point when gnus-use-article-prefetch
items are still left in the buffer.  So, underflow is trivially
testable in the consumer w/o needing a lock.

(*) Well, it's guaranteed to be at least one full item ahead of the
consumer, until it's never going to produce anymore.  (I think...:-)
This is because the producer kicks off each consumer.

Note that the current async prefetch buffer stuff makes the same
assumptions as above and works for the same reasons.

I knew all those OS courses would be useful someday. :-)

> Generating a fresh function with the proper values already there is
> much nicer, I think.

Well, it doesn't have any advantages over a static filter as far as
concurrency management is concerned: the marks in the buffer have the
same problems as any shared variables.  (One way of eliminating this
was what I wrote about the interfacwe: have the filter return a
string/generate a new buffer for each response and let the producer be
the only one using the async buffer.)

Either way is good, of course.  I prefer a static buffer because it's
conceptually simpler.  Your callbacks are kewler, of course.

-Sudish