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

[Lars Magne Ingebrigtsen <larsi@ifi.uio.no>]

Sudish Joseph <sudish@mindspring.com> 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 <server> <port> *<associated-buffer>**"),
and when an article (or whatever) has been received, it copies its
contents over to <associated-buffer> (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."