Announcements and discussions for Gnus, the GNU Emacs Usenet newsreader
 help / color / mirror / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: info-gnus-english@gnu.org
Subject: Re: Gnus fetch freezes emacs
Date: Wed, 05 Jul 2023 11:55:36 -0700	[thread overview]
Message-ID: <87v8eychnb.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87lefun5s7.fsf@gmx.net> (Stephen Berman's message of "Wed, 05 Jul 2023 10:04:08 +0200")


On 07/05/23 10:04 AM, Stephen Berman wrote:
> 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).

The nntp-connection-timeout variable has been present and nil since
1999. I put my original buggy fix in at the end of October 2021, so that
seems suspicious, but that should only have had an effect if you had set
nntp-connection-timeout to something other than the default of nil.

In general it's pretty hard to say, though...


  reply	other threads:[~2023-07-05 18:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-30 14:33 Prashant Tak
2023-06-30 19:33 ` Stephen Berman
2023-07-01 10:41   ` Eric S Fraga
2023-07-01 18:00     ` Stephen Berman
2023-07-02 15:15   ` Prashant Tak
2023-07-02 23:59     ` Eric Abrahamsen
2023-07-03 12:15       ` Eric S Fraga
2023-07-03 12:58       ` Eric S Fraga
2023-07-03 16:36         ` Eric Abrahamsen
2023-07-04 11:31           ` Stephen Berman
2023-07-04 17:02             ` Eric Abrahamsen
2023-07-04 19:55               ` Stephen Berman
2023-07-05  3:50                 ` Eric Abrahamsen
2023-07-05  8:04                   ` Stephen Berman
2023-07-05 18:55                     ` Eric Abrahamsen [this message]
2023-07-05 20:09                       ` Stephen Berman
2023-07-05 20:34                         ` Eric Abrahamsen
2023-07-05 21:05                           ` Stephen Berman
2023-07-03 19:22         ` Bob Newell
2023-07-04  8:13           ` Robert Pluim
2023-07-05 16:56             ` Gmail slowness/occasional SMTP hang Bob Newell
2023-07-02 17:37   ` Gnus fetch freezes emacs yeti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8eychnb.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=info-gnus-english@gnu.org \
    --cc=stephen.berman@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).