Re: is there a possibility for gnus to download data without blocking?

[Wayne Harris <wharris1@protonmail.com>]

dick.r.chiang@gmail.com writes:

> I am gratified someone studied my changes.

:-)

> WH> CODA ... and it's not clear what it is or what it does.
>
> CODA merely updates the message counts in *Group* after retrieval threads
> complete.

Why is it called CODA and where is the definition of the procedure?

> WH> But I think the real thing you wanted to know was how he would handle, for
> WH> the situation the intermixing of different servers returning data ...
>
> As the 90s pop song goes, one has to "keep'em separated."  

I think that's ``Come Out and Play'', by Offspring, or something like
that. :-)

> This means making "total war" on the monolithicity of the summary,
> article, and nntp buffers which Gnus has since inception assumed
> global singletons.

My idea is that nearly everything stays as it is.  I think the only
thing that should be ``parallelized'' is the download of data from nntp
servers.

> WH> Same strategy as dickmao's, but using processes, not threads.
> WH> If so, it would be way better if [Gnus] just wouldn't block.  Maybe we
> WH> don't need dickmao's threads after all.
>
> As EA previously stated, shunting all retrieval logic to a separate process B
> still poses the serious problem of integrating B's results in
> the main process A.  

Yes, but I guess the difficulty is nearly the same you're facing with
your threads.  You have to manage the threads; you'd have to manage the
processes.  Are you saying threads are easier to manage than processes?