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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  larsi@gnus.org,  50849@debbugs.gnu.org,
>   bugs@gnu.support,  visuweshm@gmail.com
> Date: Wed, 07 Sep 2022 12:34:35 +0200
> 
> >>>>> On Wed, 7 Sep 2022 04:18:17 -0400, Stefan Kangas 
> >>>>> <stefankangas@gmail.com> said:
> 
>     Stefan> You wrote that "if someone uses the client of the master branch, 
> it will
>     Stefan> now always terminate due to timeout after 30 sec", but I don't 
> see that
>     Stefan> on current master.  So I'm asking if we are not seeing the same
>     Stefan> behaviour, and if so, why that is.
> 
>     Stefan> When I do this:
> 
>     Stefan>     ./lib/emacsclient foo.txt
> 
>     Stefan> and wait for more than 30 seconds, emacsclient doesn't exit.
> 
> ...because the code on master now just retries the recv instead of
> exiting. So in normal operation without a timeout argument, the recv
> will timeout after 30 seconds, and emacsclient will go back to
> recv. Before the timeout changes it would wait in recv forever.
> 
> Thatʼs a behaviour change. I guess we could change emacsclient to set
> the timeout back to 0 in that case, but Iʼm not sure itʼs worth it.

Exactly.  I actually don't understand why we need to call setsockopt
(without checking errors) 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.  Why not just avoid setting the 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.