Re: Gnus fetch freezes emacs

[Stephen Berman <stephen.berman@gmx.net>]

On Tue, 04 Jul 2023 20:50:05 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Tue, 04 Jul 2023 10:02:34 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>>
>>> Stephen Berman <stephen.berman@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).

I don't follow you, but no need to elaborate further here.

>>>>> 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.

Feel free to open a new bug for fixing nntp-connection-timeout.  I don't
know if I can help, other than trying out suggestions and providing
feedback.  In the meantime I'll keep using my workaround replacement
function.

But I wonder, could this issue have been triggered by some change in
news.gmane.io around early to mid December 2021?  Because that's when
the problem start for me, and prior to that I don't recall ever having
this problem (perhaps sporadically but not with such persistance).

Steve Berman