From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#50849: 28.0.50; Proposal for Emacs daemon to signal when being busy Date: Wed, 7 Sep 2022 18:47:03 -0700 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38692"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, visuweshm@gmail.com, bugs@gnu.support, 50849@debbugs.gnu.org To: Eli Zaretskii , Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 08 03:48:13 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 1oW6eK-0009sz-Dk for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Sep 2022 03:48:12 +0200 Original-Received: from localhost ([::1]:34932 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oW6eI-0002q5-RW for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Sep 2022 21:48:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35476) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oW6eB-0002pv-50 for bug-gnu-emacs@gnu.org; Wed, 07 Sep 2022 21:48:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39805) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oW6eA-0002ss-Qa for bug-gnu-emacs@gnu.org; Wed, 07 Sep 2022 21:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oW6eA-0008Tq-E7 for bug-gnu-emacs@gnu.org; Wed, 07 Sep 2022 21:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 Sep 2022 01:48:02 +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.166260163232442 (code B ref 50849); Thu, 08 Sep 2022 01:48:02 +0000 Original-Received: (at 50849) by debbugs.gnu.org; 8 Sep 2022 01:47:12 +0000 Original-Received: from localhost ([127.0.0.1]:56737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oW6dM-0008RB-3M for submit@debbugs.gnu.org; Wed, 07 Sep 2022 21:47:12 -0400 Original-Received: from mail-oa1-f47.google.com ([209.85.160.47]:34326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oW6dK-0008Qz-7e for 50849@debbugs.gnu.org; Wed, 07 Sep 2022 21:47:10 -0400 Original-Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-1280590722dso7137993fac.1 for <50849@debbugs.gnu.org>; Wed, 07 Sep 2022 18:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date; bh=21ZqENB+vdSxaDWLE1cRpEQCCymhfn95Vfep7uOxt34=; b=VGKFSs+BBEDanhPzxog5xxw26speLUV4BBbpDKV2e3ygoXItsKSUlyN89lLscF+Ngq I3fbYNX4Cojz0MfMPH1JHR6GVR7Wbf+kRdGpshtmG5GBWZABhLOnegTUNozJ/clTVsMY VVlR/f24KQhK4bOWMP31O2jGWc4vCzvKvAwTiTBVac8M7qVFD97Csli3VyoMCMx8U338 rJn030wt+BYG7sxbB1s0s9MmyeT+FTv7SoRX6XZ4d9pva3nkmVEQ5Qq5nJjizNcmqcFv U9Yp+/BfzAJqGRo+t2V9W2MHpbEqo5VQwZlB9tCWMmQZk9d+0DtVUCQ3TG6KeGjRN/Th 7ACQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date; bh=21ZqENB+vdSxaDWLE1cRpEQCCymhfn95Vfep7uOxt34=; b=SLa2R+nrOaN3EelIRePDZmgtQ4uxXt/0YWiV9cqAt5hmqFhCM70Lk5qba7vYtINueE mJYZQImxgKeAi97iAnTxdAFM99QFvFsNQCDX7oS8ZIy8/NwSUNVo6JRIqoWuhNCC0gU4 XRgV+Az4AYDmwO9UiWCAjXVzrOYJ5zIgHIjasWThII6awvExJHl+GG8PEJsqCsF9Nxkm 6c1P3vEt3uUaThDL2/Nkk7uYfDAlUm07ChXmd9ddb58KwfKZHquzgcVwxCEopCIJ3drF xLiaI5qeW92SZE9fsDm22J908HdUY+pDCy5ETaDhKbEI2foK/nwF+pSDdKoY7UOELrGM N1VA== X-Gm-Message-State: ACgBeo1gHC+7r3Lve+UdDw/xBMRPZIia81PZmIUh8J9trr9J/rJeYNsl 51foyuJhRdGwQ1+EE/rZPdyz6JV8X8wAHgRZy3Y= X-Google-Smtp-Source: AA6agR6dmavruJkz1BxBj63pb3kPOiQz/GkfpbEuwaiceAT/yYRtrM/aSGELMUDsR5wgC1cuie538YbeemNK5+qXb18= X-Received: by 2002:a05:6870:5581:b0:11e:300:8189 with SMTP id n1-20020a056870558100b0011e03008189mr639763oao.199.1662601624540; Wed, 07 Sep 2022 18:47:04 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Sep 2022 18:47:03 -0700 In-Reply-To: <838rmvig8f.fsf@gnu.org> X-Hashcash: 1:20:220908:50849@debbugs.gnu.org::87vgPCO5OZmxfPQI:7iNA 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:241810 Archived-At: Eli Zaretskii writes: > I actually don't understand why we need to call setsockopt We need to call setsockopt to set the timeout. Based on section 13.2 in UNIX Network Programming, I guess we could call alarm(2) and set up a SIGALRM handler instead. (But that seems to have been mentioned there mostly in case you need to use an implementation that doesn't support SO_RCVTIMEO, so I'm not sure it's a good idea.) > (without checking errors) Adding error handling is easy enough, but what do you think we must do differently if the call to setsockopt fails? 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. > 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? And what does "etc." above mean? Regarding msg_showed, I think you're right that it should be initialized to a constant value instead. > 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. > 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. (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.)