bug#50849: 28.0.50; Proposal for Emacs daemon to signal when being busy

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefankangas@gmail.com>
> 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 <eliz@gnu.org> 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.