From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23520 invoked from network); 5 Jul 2023 18:56:23 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 5 Jul 2023 18:56:23 -0000 Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qH7fb-0003bF-BC; Wed, 05 Jul 2023 14:56:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qH7fC-0003aY-La for info-gnus-english@gnu.org; Wed, 05 Jul 2023 14:55:42 -0400 Received: from mail.ericabrahamsen.net ([52.70.2.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qH7fA-00037y-Qq for info-gnus-english@gnu.org; Wed, 05 Jul 2023 14:55:42 -0400 Received: from localhost (c-71-197-232-41.hsd1.wa.comcast.net [71.197.232.41]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 2D8D2FA002; Wed, 5 Jul 2023 18:55:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1688583338; bh=TPyos04IKl5E/MORSXDtRnwbneun5m6+2XTNuuw8KS0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KDXmXGg2sUThb47naTuYStSNTRO031zcTaqb4Q+32EpNwFowXkbPlZLJQX2ylCHMj g+kiRRbGpwg2snR4dIhKG46lISAHwTvuzpH3A9ZhD0Il/HB01g5+Yu2YGljeBgG0FC cUwWGbzvlIfy6bkdejt6jCLypqxJ3VC5cUF02rvU= From: Eric Abrahamsen To: Stephen Berman Cc: info-gnus-english@gnu.org Subject: Re: Gnus fetch freezes emacs In-Reply-To: <87lefun5s7.fsf@gmx.net> (Stephen Berman's message of "Wed, 05 Jul 2023 10:04:08 +0200") References: <87sfa9nhp4.fsf@gmail.com> <87ttuoeoej.fsf@gmx.net> <87mt0e1h0u.fsf@gmail.com> <87h6qlsw3n.fsf@ericabrahamsen.net> <87o7ktjgmw.fsf@ucl.ac.uk> <87zg4dq7ed.fsf@ericabrahamsen.net> <87wmzfx69o.fsf@gmx.net> <87v8ezehjp.fsf@ericabrahamsen.net> <87sfa3wiwu.fsf@gmx.net> <87mt0bdnki.fsf@ericabrahamsen.net> <87lefun5s7.fsf@gmx.net> Date: Wed, 05 Jul 2023 11:55:36 -0700 Message-ID: <87v8eychnb.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: info-gnus-english@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Announcements and discussions for GNUS, the GNU Emacs Usenet newsreader \(in English\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org Sender: info-gnus-english-bounces+ml=inbox.vuxu.org@gnu.org On 07/05/23 10:04 AM, Stephen Berman wrote: > On Tue, 04 Jul 2023 20:50:05 -0700 Eric Abrahamsen wrote: > >> Stephen Berman writes: >> >>> On Tue, 04 Jul 2023 10:02:34 -0700 Eric Abrahamsen wrote: >>> >>>> Stephen Berman 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...