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.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21099 invoked from network); 5 Jul 2023 03:50:31 -0000 Received: from lists.gnu.org (209.51.188.17) by inbox.vuxu.org with ESMTPUTF8; 5 Jul 2023 03:50:31 -0000 Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGtX2-0006nX-LR; Tue, 04 Jul 2023 23:50:20 -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 1qGtX1-0006nM-FW for info-gnus-english@gnu.org; Tue, 04 Jul 2023 23:50:19 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGtWy-00063m-U4 for info-gnus-english@gnu.org; Tue, 04 Jul 2023 23:50:19 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qGtWw-0002c9-Sp for info-gnus-english@gnu.org; Wed, 05 Jul 2023 05:50:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: info-gnus-english@gnu.org From: Eric Abrahamsen Subject: Re: Gnus fetch freezes emacs Date: Tue, 04 Jul 2023 20:50:05 -0700 Message-ID: <87mt0bdnki.fsf@ericabrahamsen.net> 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> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:T4XUkR8KJ98De+nUtmu7nuxk+/I= Received-SPF: pass client-ip=116.202.254.214; envelope-from=gegu-info-gnus-english@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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 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). >>>> 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