bug#71223: 30.0.50; stack overflow after very fast opening and closing of frames

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> Could you try the patch below which sequentializes the processing of the
>> process-filters to avoid such recursion?
>
> Running on d9512da49514623ef3e35524dc894c06f2c0ce20 (from yesterday)
> with only this patch, and a simple loop (10 seconds are enough):
>
> for j in `seq 10`; do for i in `seq 10`; do urxvt -e emacsclient '-nw'
> '-e' '(dired "~")' &; done; sleep 1 && killall emacsclient; done
>
> (gdb) run --fg-daemon -Q
> Starting program: /opt/dc/emacs/bin/emacs --fg-daemon -Q
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Starting Emacs daemon.
> [Detaching after vfork from child process 1028]
> [Detaching after vfork from child process 1033]
> [Detaching after vfork from child process 1034]
> process server <5> no longer connected to pipe; closed it
> Process server <6> not running: connection broken by remote peer

AFAICT this is because you kill those processes with `killall
emacsclient` so when Emacs finally wants to send the "result" back, the
`process-send-string` fails with the above error.

IOW, I'm not sure it reflects a bug in Emacs.

> At that point, it's unresponsive and I can't open new emacsclient.
> They open a black window, where after a time I see "Server not
> responding". If I wait until all the "connection broken" errors slowly
> end, then these frames will load (i.e. dired is visible), and new
> frames will load too.

Actually, if you hit a key within the Emacs frame you presumably have
opened, it should finish those things without waiting (the 2s waits are
done with `sit-for` which waits only when there's no pending user input).

> With casual usage, i.e. just opening a few frames and closing them
> after they are fully loaded (visible text inside) there are no
> "connection broken" messages. I think the error appears only when I'm
> closing a frame that was still in the process of being opened.

IIUC this problem is not really new with my code (tho, I guess when the
process-filters are run in a nested fashion, the various `sit-for` can
be done in parallel, whereas with my patch they are done sequentially,
significantly increasing the visible delay when you have many such
requests).

The better solution is to eliminate the remaining `sit-for`s (e.g. using
some new `message-timed` function which displays a message during at
least N seconds but returns immediately), of course.


        Stefan