Re: Excessively Painful Forwards

[Greg Stark <gsstark@mit.edu>]

On the other hand it would not be hard to do this for network-bound interfaces
such as nntp. In fact the basic infrastructure in nntp.el is there already,
all that's needed now is support from gnus itself in the form of an
asynchronous backend interface.

I have a backend here that uses recursive edits to demonstrate how useful this
would be and it's proven extremely useful. Unfortunately recursive edits don't
scale as a way to do this. In particular they wouldn't work well if multiple
backends tried to use this technique... 

It might be tricky but basically what gnus needs is an option to provide to
the backend that would be a closure to call when the operation was finished.
Then the backend could schedule all its work and return immediately. Taking
care of the processing of data in callbacks, calling the closure when it's
finished. 

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Chris Richards <cjr@netpliance.net> writes:
> 
> > On a related note, gnus hangs my xemacs session when it
> > checks/parses/splits news and mail.  Is this a limitation of the
> > architecture or this there a way to background these tasks?
> 
> In principle, it is possible to background these tasks, but it is very
> hard to code due to the limited form of (cooperative) multitasking
> implemented in Emacs.
> 
> You would have to recode Gnus such that it does its work in small
> chunks: when you hit `g', the first chunk is scheduled for a time when
> Emacs is idle.  Just before finishing, the first chunk schedules a
> second chunk for a time when Emacs is idle, and so on.  This would be
> a decidedly nontrivial undertaking.
> 
> kai
> -- 
> ~/.signature: No such file or directory
> 

-- 
greg