Stephen Berman <stephen.ber...@gmx.net> writes: > On Tue, 04 Jul 2023 10:02:34 -0700 Eric Abrahamsen <e...@ericabrahamsen.net> > wrote: > >> Stephen Berman <stephen.ber...@gmx.net> writes:
[...] > This: > > (defun srb-gnus-group-get-new-news (&optional arg one-level) > (interactive "P") > (with-timeout (1 (kill-buffer (nntp-find-connection-buffer > nntp-server-buffer)) > (gnus-group-get-new-news)) > (gnus-group-get-new-news arg one-level))) > > (define-key gnus-group-mode-map "g" 'srb-gnus-group-get-new-news) > >> Eric F is just describing the >> unfortunate behavior of nntp-connection-timeout, which interrupts the >> entire fetching process when it hits the timeout. > > Is that different than what the above function does with the kill-buffer > sexp? (Not a rhetorical question, I know next to nothing about news > servers and their connectivity issues.) The `nntp-connection-timeout' variable has different behavior in that NNTP servers are allowed one "retry" if the connection fails. The code around that is very confusing to me (which is why my earlier fix was buggy). >>>> Yeah, I'd put in a dumb fix for this that turned out to be buggy, so we >>>> just recently reverted it. I have a more thorough fix in progress >>>> somewhere here, that would report a server connection failure without >>>> interrupting the rest of the servers, but it's not done yet. I've had >>>> very little time for coding recently, but will get to it At Some Point. >>>> >>>> Glad it's at least better than it was. I wonder if we should have some >>>> generous timeout set by default... >>> >>> It might make sense to continue this discussion in bug#52735. >> >> This doesn't seem like the same issue -- this problem is pretty well >> understood. > > Hm, I had understood from both Prashant Tak and Eric Fraga that the > problem they have is essentially the same as I do and what I reported in > that bug. But that problem doesn't seem to be understood. If by the > understood problem you mean the effect of nntp-connection-timeout, > doesn't that just mean using it isn't a real fix for the hang the three > of us (at least) are experiencing? That's why I thought other > approaches need to be considered and bug#52735 seems like the > appropriate venue for that. But I'm fine with continuing the discussion > here instead. Oh I see what you mean. In your bug report I'd gotten the idea that something was going wrong with accepting process output, and had a missed-the-forest-for-the-trees moment around it simply being a dead process. Using `nntp-connection-timeout' is the proper fix for this problem, it's just got a bit of unfortunate behavior that needs to be remedied. I'd be inclined to start a whole new bug report for a fix for that, because it's really a new issue, with its own larger-reaching design decisions. I suppose we could merge #52735 with that, though. Eric
