From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/7499 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: Re: [ patch ] async stuff fix(?) (was Re: 0.3 and async pre-fetch) Date: 06 Aug 1996 02:08:16 -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 1035147803 7428 80.91.224.250 (20 Oct 2002 21:03:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:03:23 +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 XAA03416 for ; Mon, 5 Aug 1996 23:38:45 -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 ; Tue, 6 Aug 1996 08:03:53 +0200 Original-Received: (from sj@localhost) by atreides.erehwon.org (8.7.5/8.7.3) id CAA00375; Tue, 6 Aug 1996 02:08:17 -0400 Original-To: ding@ifi.uio.no In-Reply-To: Lars Magne Ingebrigtsen's message of 05 Aug 1996 19:11:53 +0200 Original-Lines: 48 X-Mailer: Red Gnus v0.5/XEmacs 19.14 Xref: main.gmane.org gmane.emacs.gnus.general:7499 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:7499 In article , Lars Magne Ingebrigtsen 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