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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: cyd@stupidchicken.com,  n142857@gmail.com,  71223@debbugs.gnu.org
> Date: Thu, 30 May 2024 12:09:30 -0400
> 
> > AFAIR, the waits are for 2 purposes:
> >
> >   . let the user of emacsclient see the error messages sent by the
> >     server (because deleting the process clears the terminal);
> 
> 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.

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

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