Re: Gnus fetch freezes emacs

[Stephen Berman]

On Tue, 04 Jul 2023 10:02:34 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> 
wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Mon, 03 Jul 2023 09:36:26 -0700 Eric Abrahamsen <eric@ericabrahamsen.net> 
>> wrote:
>>
>>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>>>
>>>> On Sunday,  2 Jul 2023 at 16:59, Eric Abrahamsen wrote:
>>>>> If everyone's hitting this with NNTP servers, you can set
>>>>> `nntp-connection-timeout' to a number of seconds. It is nil by default,
>>>>> which I guess would result in permanent hangs.
>>
>> Is this variable supposed to be set in the value of gnus-select-method?
>> For example, like this:
>>
>> (setq gnus-select-method '(nntp "news.gmane.io"
>>                              (nntp-connection-timeout 3)))
>
> It's a defvoo, so it can either be set globally, or as a server
> parameter.

Ok, thanks.

>>>> So this works, in the sense that it stops me waiting forever... However,
>>>> it seems (early days yet) that when it fails to open the connection to
>>>> an NNTP server, it stops retrieving news and I have to hit 'g' again to
>>>> get the counts etc. updated for other servers. [...]
>>
>> That sounds basically like what the function I'm using in place of
>> gnus-group-get-new-news (see my first post in this thread) does.  Could
>> such a function take effect if added to one of the server hook variables
>> nntp-server-opened-hook, nntp-server-action-alist or
>> nntp-open-connection-function?  From the descriptions in the manual it
>> isn't clear to me.  Or is there some better Gnus hook variable for this
>> purpose?  If not could one be added?
>
> I'm not sure what function you mean.

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

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

Steve Berman