From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#50849: 28.0.50; Proposal for Emacs daemon to signal when being busy Date: Wed, 07 Sep 2022 14:19:44 +0300 Message-ID: <838rmvig8f.fsf@gnu.org> References: <86czouksh2.fsf@protected.rcdrun.com> <83mtnykpij.fsf@gnu.org> <87tui5fdku.fsf@gnus.org> <83y27hjhy2.fsf@gnu.org> <87r10uvxr9.fsf@gnus.org> <83o7vyowcl.fsf@gnu.org> <87czceufj1.fsf@gnus.org> <83ilm6osqz.fsf@gnu.org> <87sflaszct.fsf@gnus.org> <874jxpevb6.fsf@gmail.com> <838rn1q3g9.fsf@gnu.org> <87edwsiy9p.fsf@gnus.org> <87a67d1vyg.fsf@gnus.org> <83ilm1jkss.fsf@gnu.org> <87v8q1b2ij.fsf@gmail.com> <83czc8k7zw.fsf@gnu.org> <83czc7j4bs.fsf@gnu.org> <87leqvbhhg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2801"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, visuweshm@gmail.com, stefankangas@gmail.com, bugs@gnu.support, 50849@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 07 13:22:33 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oVt8b-0000Wv-1L for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Sep 2022 13:22:33 +0200 Original-Received: from localhost ([::1]:59712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oVt8a-0007Fl-1U for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Sep 2022 07:22:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVt7B-0006Ht-2S for bug-gnu-emacs@gnu.org; Wed, 07 Sep 2022 07:21:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36760) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oVt78-0007WQ-1u for bug-gnu-emacs@gnu.org; Wed, 07 Sep 2022 07:21:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oVt77-0006Xb-Ll for bug-gnu-emacs@gnu.org; Wed, 07 Sep 2022 07:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Sep 2022 11:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50849 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 50849-submit@debbugs.gnu.org id=B50849.166254961125074 (code B ref 50849); Wed, 07 Sep 2022 11:21:01 +0000 Original-Received: (at 50849) by debbugs.gnu.org; 7 Sep 2022 11:20:11 +0000 Original-Received: from localhost ([127.0.0.1]:53692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVt6I-0006WM-Lm for submit@debbugs.gnu.org; Wed, 07 Sep 2022 07:20:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oVt6F-0006W7-Vj for 50849@debbugs.gnu.org; Wed, 07 Sep 2022 07:20:09 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52620) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVt6A-00072E-Fg; Wed, 07 Sep 2022 07:20:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=G0hu6hCcTEpLdB6vCuuggfaSf1RJsjPST7OZzKsLIhc=; b=GMQpxtA+BRuuOaqmzrZX ltrvp355h4IWuLgxlJACKTMrpbozEgFGL2D8WlVl+fblPkqdojPU2uCdkkuDEcERFJVW2tqt0bLUY WMg5eZmXk9LbNnW77PGWWeeDjdm/ziw+RYj4q/Tq7Mwsmpf0oNYs5cDDmgJ3dr/338YTQLaQeNqDv xJHxKpNFSl6+5S2afpBgiEDOhkXRgqbUE5kfc8UsLnj0bf0/Hf4hVgJDtme+95YJM+VMQJy0IUyr0 o68QjahJoORfGe17QwsRAf/D04YUnOaZhtjg7u9h16XGn/RD4r4RaAFX+dxqJHCazOTSlNJrDFyp9 Uaaf4D+K1sKQIg==; Original-Received: from [87.69.77.57] (port=3215 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oVt69-0001GX-Vh; Wed, 07 Sep 2022 07:20:02 -0400 In-Reply-To: <87leqvbhhg.fsf@gmail.com> (message from Robert Pluim on Wed, 07 Sep 2022 12:34:35 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:241738 Archived-At: > From: Robert Pluim > Cc: Eli Zaretskii , larsi@gnus.org, 50849@debbugs.gnu.org, > bugs@gnu.support, visuweshm@gmail.com > Date: Wed, 07 Sep 2022 12:34:35 +0200 > > >>>>> On Wed, 7 Sep 2022 04:18:17 -0400, Stefan Kangas said: > > Stefan> You wrote that "if someone uses the client of the master branch, it will > Stefan> now always terminate due to timeout after 30 sec", but I don't see that > Stefan> on current master. So I'm asking if we are not seeing the same > Stefan> behaviour, and if so, why that is. > > Stefan> When I do this: > > Stefan> ./lib/emacsclient foo.txt > > Stefan> and wait for more than 30 seconds, emacsclient doesn't exit. > > ...because the code on master now just retries the recv instead of > exiting. So in normal operation without a timeout argument, the recv > will timeout after 30 seconds, and emacsclient will go back to > recv. Before the timeout changes it would wait in recv forever. > > Thatʼs a behaviour change. I guess we could change emacsclient to set > the timeout back to 0 in that case, but Iʼm not sure itʼs worth it. Exactly. I actually don't understand why we need to call setsockopt (without checking errors) and then complicate our lives with no less than 3 tricky-named flags ('retry' is not really what its name says, msg_showed is initialized with a non-fixed value, etc.) when the timeout was not given. Why not just avoid setting the timeout in that case? And in any case, saying that the default timeout is zero is simply misleading. We should either say that "by default emacscilent will wait indefinitely" or modify DEFAULT_TIMEOUT to zero.