From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/7503 Path: main.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: [ patch ] async stuff fix(?) (was Re: 0.3 and async pre-fetch) Date: 06 Aug 1996 22:51:18 +0200 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035147806 7433 80.91.224.250 (20 Oct 2002 21:03:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:03:26 +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 TAA15542 for ; Tue, 6 Aug 1996 19:11:38 -0700 Original-Received: from hler.ifi.uio.no (hler.ifi.uio.no [129.240.94.23]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 7 Aug 1996 03:18:49 +0200 Original-Received: (from larsi@localhost) by hler.ifi.uio.no ; Wed, 7 Aug 1996 03:19:07 +0200 Original-To: ding@ifi.uio.no In-Reply-To: Sudish Joseph's message of 06 Aug 1996 02:08:16 -0400 Original-Lines: 26 X-Mailer: Red Gnus v0.7/Emacs 19.29 X-Face: &w!^oO~dS|}-P0~ge{$c!h\\ writes: > 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, but all this isn't really an issue -- we don't have a general producer/consumer situation. We instead have an, uhm, link of actions -- fetch, wait, fetch, wait, etc. Sort of. So you seem to be adding complexity to a situation I thought was rather simple... -- "Yes. The journey through the human heart would have to wait until some other time."