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

[Stefan Kangas <stefankangas@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.

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.)