GNU bug report logs - #50849
28.0.50; Proposal for Emacs daemon to signal when being busy

Previous Next

Package: emacs;

Reported by: Jean Louis <bugs <at> gnu.support>

Date: Mon, 27 Sep 2021 14:28:02 UTC

Severity: wishlist

Tags: patch

Found in version 28.0.50

Fixed in version 29.1

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #111 received at 50849 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Cc: larsi <at> gnus.org, visuweshm <at> gmail.com, bugs <at> gnu.support,
 50849 <at> debbugs.gnu.org
Subject: Re: bug#50849: 28.0.50; Proposal for Emacs daemon to signal when
 being busy
Date: Wed, 7 Sep 2022 18:47:03 -0700
Eli Zaretskii <eliz <at> gnu.org> 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.)




This bug report was last modified 2 years and 256 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.