From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/7493 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: 05 Aug 1996 19:11:53 +0200 Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035147798 7408 80.91.224.250 (20 Oct 2002 21:03:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:03:18 +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 NAA32111 for ; Mon, 5 Aug 1996 13:43:32 -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 ; Mon, 5 Aug 1996 22:28:41 +0200 Original-Received: (from larsi@localhost) by hler.ifi.uio.no ; Mon, 5 Aug 1996 22:28:58 +0200 Original-To: ding@ifi.uio.no In-Reply-To: Sudish Joseph's message of 04 Aug 1996 18:09:51 -0400 Original-Lines: 65 X-Mailer: Red Gnus v0.6/Emacs 19.29 X-Face: &w!^oO~dS|}-P0~ge{$c!h\\ writes: > The problem here was that there were two different functions trying to > define "this is the article" independent of the other -- the filter > and gnus-async-prefetch-article. No, the filter has no idea that it's fetching an article at all. The filter (and only the filter) fuzzes around in its process buffer (which is called " *server ***"), and when an article (or whatever) has been received, it copies its contents over to (which is the asynch article buffer in this case) and calls the callback function. > The downside to using strings is that we'll get -large- strings that > will hog memory until garbage collection. Is there any way to > truncate the actual string to get around this? Nope. > Hmm, do buffers cost more/less than strings? "Less, but the same." The memory occupied by buffers is returned to the system when they are killed. > We might pass buffers as our result from the filter if that's > better. Buffers aren't gc'ed I think, but we can manually maintain > those quite easily. Well, killed buffers take no space. > 2) Eliminate the need to generate callbacks dynamically in > gnus-async-prefetch-article by having that function keep a queue of > sent commands that'll be used by a static callback (a defun'ed, > non-backquote generated, function) to match group/article combinations > to received responses (assuming that responses are received in the > correct order...seems reasonable). Keep that queue buffer-local to > allow for multiple summary prefetches to work at once. > > This would a) make debugging this stuff stop being a major pita, > > b) make it easier to understand, c) reduce gc (there's a lambda > 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. Generating a fresh function with the proper values already there is much nicer, I think. > PS: If anyone would care to explain: can buffers be gc'ed? Yes. > are lambda's gc'ed (if not, gnus currently leaks)? A `(whatever) form is just a list, so, yes. > can an arbitrary object be completely destroyed/gc'ed all by itself? No. -- "Yes. The journey through the human heart would have to wait until some other time."