GNU bug report logs - #38136
[PATCH] Make gnus-group-get-new-news a non blocking thread

Previous Next

Full log

Message #55 received at 38136 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: dick.r.chiang <at> gmail.com
Cc: Robert Pluim <rpluim <at> gmail.com>, 38136 <at> debbugs.gnu.org
Subject: Re: bug#38136: https://github.com/dickmao/gnus
Date: Mon, 25 Nov 2019 11:02:28 -0800

dick.r.chiang <at> gmail.com writes:

> RP> That, plus the patch has spurious whitspace changes, and things like the
> RP> below, which makes it all harder to read.
>
> I've a mind, of course, to bring non-blocking goodness to the main branch, but
> the volume of changes (more than 200 commits and counting at
> github.com/dickmao/gnus) requires a social effort that may never reach critical mass.

Don't give up hope! But I definitely recommend starting the social
effort part of things before you invest enormous amounts of time in code
(too late, I know). This is a collaborative effort, and people have
*very* strong opinions about how their Gnus behaves, and you're better
off floating ideas sooner rather than later -- for example, any one of
us could have told you that requiring users to set `gnus-select-methods'
via customization (and not `setq') was probably a non-starter. Which
could have saved you some time!

> The original patch wishfully believed dynamic-letting globals like
> `gnus-summary-buffer` would do an end-run around thread-safety.  But "leakage"
> occurs far too often as manifested by "Selected deleted buffer" errors.

Every time I've embarked on grand refactorings of Gnus I've run up
against problems like this -- every part of Gnus is tied so tightly to
every other part, it's very hard to unpick. So I've started working
backwards from the big goals. Do we want threaded server updates?
`nntp-server-buffer' is the problem. So each server should probably have
its own "work buffer". The easiest way to make that happen is if servers
are structs. And on down from there, trying to work down to a root
problem that, when solved, will reduce complexity instead of increasing
it, and boost modularity rather than causing tighter code integration.

Then I still screw it up in the end, but hey, I think it's the right
approach.

I think a lot of our problems will be made more tractable by getting rid
of code that assumes a "current" thing. The "current" server. The
"current" group. The "current" summary buffer. Pass arguments, don't
check dynamic variables. Maybe that would be a better place to start.

That patch that could end up enabling the big refactors later might not
look like much at first glance.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.