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: Thu, 08 Sep 2022 08:59:40 +0300 Message-ID: <83wnaefltf.fsf@gnu.org> References: <86czouksh2.fsf@protected.rcdrun.com> <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> <838rmvig8f.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8805"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rpluim@gmail.com, visuweshm@gmail.com, larsi@gnus.org, bugs@gnu.support, 50849@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 08 08:01:37 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 1oWAbZ-00028n-5K for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Sep 2022 08:01:37 +0200 Original-Received: from localhost ([::1]:52178 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWAbX-00061I-Tq for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Sep 2022 02:01:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49348) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWAb0-0005zf-Jn for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2022 02:01:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40070) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oWAb0-0004Zt-AT for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2022 02:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oWAb0-0002ZR-0z for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2022 02:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Sep 2022 06:01: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.16626168059722 (code B ref 50849); Thu, 08 Sep 2022 06:01:01 +0000 Original-Received: (at 50849) by debbugs.gnu.org; 8 Sep 2022 06:00:05 +0000 Original-Received: from localhost ([127.0.0.1]:57002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWAa4-0002Wi-Lu for submit@debbugs.gnu.org; Thu, 08 Sep 2022 02:00:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWAa2-0002Vh-Aa for 50849@debbugs.gnu.org; Thu, 08 Sep 2022 02:00:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56168) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWAZw-00046Y-Sd; Thu, 08 Sep 2022 01:59:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=LpmWINUWpJEVO8kD10MORT4rQwMGjpnqrxMxrdEbf+M=; b=e7Anw6pwh/Kr yFQsm2+78z0JCVXLVH62AtveYAuWRjY1AUZvOFS14X5MepEV4DMjvO94snBx2R4DGXwxBp+OM7+71 1ypo1fFDyLBBwQHemrkk87O2TIw7V08p2CFgOG05oSrEvsLL9ge9rwt1sfetIKra56kzxAPeey5BT cjeyX0TspW5MNRtw9OmzebqfdnXzP1Y03JS65pn9iZ18loYaQLOuWJl6UQKMQfjRioEgIogUp/Z1P sVyabhvhzSIIKXiH8wXHXcgyzzmD4HbHDSqGlJQKQ8PljAF4FLtSmEQain1CLMomsyzjU0fwX7/Op 4jcLz463VKbrSyTeZx5VkA==; Original-Received: from [87.69.77.57] (port=3925 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 1oWAZw-0000AX-6E; Thu, 08 Sep 2022 01:59:56 -0400 In-Reply-To: (message from Stefan Kangas on Wed, 7 Sep 2022 18:47:03 -0700) 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:241825 Archived-At: > From: Stefan Kangas > Date: Wed, 7 Sep 2022 18:47:03 -0700 > Cc: larsi@gnus.org, 50849@debbugs.gnu.org, bugs@gnu.support, > visuweshm@gmail.com > > Eli Zaretskii writes: > > > I actually don't understand why we need to call setsockopt > > We need to call setsockopt to set the timeout. When the timeout wasn't given by the user, I don't think it's our business to second-guess what the user wants. Setting a timeout in all cases is at least an incompatible behavior change. For example, imagine a use case where the delay is indeed justified, and the user has no problems having emacsclient to wait for more than 30 sec. With the current code on master, we will output messages that we previously didn't, and that could potentially break someone's scripts. Moreover, there's no way for users in such cases to get back the old behavior, none whatsoever. I don't see how can we justify such an incompatible change. The imaginary case I described is probably rare at best, but it's still a legitimate one, and we had better avoided breaking it, unless we have a very good reason. > Based on section 13.2 in UNIX Network Programming, I guess we could call > alarm(2) and set up a SIGALRM handler instead. SIGALRM is non-portable, so it's a non-starter. > > (without checking errors) > > Adding error handling is easy enough, but what do you think we must do > differently if the call to setsockopt fails? Display an error message? > IIUC, the recv call will just not timeout in that case, and things > will be as if we hadn't tried to set any timeout at all. Exactly. But it means the user asked us to do something, and we didn't. The textbook behavior in such cases is to let the user know that the contract was broken. > > 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. > > What would you name these flags instead? Something that really tells us what they signify and how they are used. When there are 3 flags whose different combinations mean different things, the code can be difficult to follow, understand, and modify safely. > And what does "etc." above mean? That I could continue telling why the current flag-based implementation is hard to read and understand. At the very least, we should have comments there explaining the logic. > > Why not just avoid setting the timeout in that case? > > Because we want to give the informational message "Server not > responding; use Ctrl+C to break". If we don't want that message, we > don't need to set a timeout in that case. See above: when the user doesn't use --timeout, he/she doesn't necessarily want emacsclient to brag about the server not responding. > > 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. > > I think it makes sense to change the documentation as you suggest. Then please do. We currently don't describe the default behavior correctly. (Of course, if you eventually agree to change the code so that no timeout is set on the socket, we just need to say that by default there's no timeout.) > (Note that DEFAULT_TIMEOUT really only has to do with the time to wait > before printing an informational message, in the case when we did not > get a --timeout flag. Maybe it could get a better name.) Either a better name (but what would be such a name?), or better comments and documentation telling what it does.