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

>> > +(defun server--sit-for (proc seconds)
>> > +  "Like `sit-for', but disable filter of process PROC and don't redisplay."
>> > +  (let ((orig-filter (process-filter proc)))
>> > +    (unwind-protect
>> > +        (progn
>> > +          (set-process-filter proc nil)
>> > +          (sit-for seconds t))
>> > +      (set-process-filter proc orig-filter))))
>> 
>> Hmm... (set-process-filter proc nil) means that any process output will
>> be sent to the process's buffer rather than to the filter, which doesn't
>> sound right (it will make us miss that process output, basically).
>> 
>> If we want this to work well we need to store the process output we
>> receive during the `sit-for` and call the process filter in it afterwards.
>
> At this point we don't expect any output from the process, and if it
> comes, don't want to know about it nor process it.

Why don't we want to process it?
[ I understand why we don't want to process it *now* but why wouldn't
  we want to process it later?  ]

>> Another option would be to offer a way to temporary suspend the
>> reception of process output for a specific process.  For most processes,
>> suspending reception of process output while running the process filter
>> would be the right thing to do, so even better would be to do that
>> automatically and offer instead a way for a process filter to explicitly
>> enable running itself recursively when/were it is needed.
> The problem here is that the process filter calls sit-for, which reads
> process output, which also calls the process filter, etc., etc. -- a

That was my understanding, indeed.  But that seems to contradict:

    At this point we don't expect any output from the process, and if it
    comes, don't want to know about it nor process it.

Oh... wait I think I understand: it's the same process-filter but not
the same process.  So your `set-process-filter` won't make
a difference and my suggestion to suspend reception of this process's
output won't help either.

>> We should devise a variant of `message` which guarantees that the message
>> is shown for at least N seconds but without having to wait for the
>> N seconds to pass before running the rest of the code.
> AFAIU, 'message' is not the problem, the problem is not to delete the
> process object too quickly, because that causes all kinds of
> unpleasant effects on the client side (see the bug reports related to
> changes in these areas).

In this specific case, it seems the relevant execution path goes through
one of the other `sit-for`, indeed.  But in theory the same could happen
with this `sit-for` so it would be good to get rid of it as well.

>> I think a better option here is to run the `delete-process` from
>> a timer, so we can *really* return immediately.
> Then, in the scenario of this bug report, we could have large amounts
> of processes we haven't chance to delete yet, because timers were not
> run before the next connection starts.

Sure.  I don't see why that would be a problem, tho.


        Stefan