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>]

>> In my patch these are mostly kept except they are short-circuited when
>> there's already some other emacsclient process filtering pending.
>> In practice this should rarely make a difference: you need to have at
>> least 3 more-or-less-concurrent emacsclients for the difference to show
>> up (the first is processed normally, and if there's no 3rd, then by the
>> time we process the second there's no other thing pending).
>
> I'm talking about the mostly-normal situation when a single client
> connects and that results in an error.

Right, and indeed my code is careful to wait just like old code did, in
that case.

>> >   . let the server and the client have enough time to undo the
>> >     terminal settings they did when the session started, so that the
>> >     terminal is left in workable condition after the client exits.
>> 
>> These are kept in the form of timers instead of `sit-for`.
>> 
>> > The bug(s) in question should tell the details.
>> 
>> I don't know which bugs these are, sadly.
>
> "git log -L" indicates that it's bug#63629.

Hmm... I wonder I didn't see it in my `vc-region-history`...
Oh, that's because it's something else:

    commit d6f717cd1dc373707440011a1552b78de2654bba
    Author: Eli Zaretskii <eliz@gnu.org>
    Date:   Fri May 26 13:20:56 2023 +0300
    
        Fix emacsclient when there are irrecoverable file-visiting errors
        
        * lisp/server.el (server-process-filter, server-return-error):
        Display the error message to be sent to the client as a regular
        message, to give the user the opportunity to see it.  Delete the
        terminal immediately after sending the error message to the
        client, to make sure the terminal's modes are restored.
        (Bug#63629)

is the one where we add the "message + sit-for for 2 seconds" as well as
the calls to `delete-terminal`.
[ Code which I mostly leave untouched, at least for the "simple" case
  of a single emacsclient at a time.  ]

Whereas my question is about

    commit 2a847524ab57b1b3d6eaa7e12b96be52dbb79509
    Author: Chong Yidong <cyd@gnu.org>
    Date:   Sat Oct 2 20:03:44 2010 -0400
    
        * lisp/server.el (server-process-filter, server-return-error): Give
        emacsclient time to shut down after receiving an error string.
        
        * etc/NEWS: Document tweak to emacsclient exit status.

which added the two `sit-for`s (of 1s and 5s respectively) just before
`delete-process`.

>> [ I must say I don't understand why we need to wait and then call
>>   `delete-process`.  ]
>
> Because delete-process disconnects us from the terminal, and if we do
> that too soon, then neither the error message we sent to the client
> nor even the terminal resetting commands will get to their
> destination.  Or so I concluded at the time; I don't consider myself
> an expert on this stuff.

I find it odd that "send" followed by "delete process" can result in the
send being lost, tho.  It seems like it reflects a bug somewhere else.
But I'm not an expert in this at all either.  E.g. I can't remember why
we need to `delete-process`.


        Stefan