Subject: bug#33747: 26.1; process-send-string exceeds max-specpdl-size

From: Eli Zaretskii <[email-masked]>
Date: Fri, 14 Dec 2018 21:54:48 +0200

> From: Markus Triska <[email-masked]>
> Cc: [email-masked]
> Date: Fri, 14 Dec 2018 19:50:39 +0100
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > AFAIK, process-send-string is a blocking function: it cannot return
> > before the entire string was sent.
> 
> Yes indeed. However, the C function send_process internally calls
> wait_reading_process_output

That's so as not to wedge the entire session.  Communications with
async subprocesses aren't supposed to stop everything in its tracks.

> and this may again invoke the filter!

In general, calling APIs that could take a long time from a process
filter is not a very good idea, btw.  Remember that process filters
are run when Emacs is idle, so when you call an API that could take a
long time, you make Emacs less responsive.  And then there's the
infinite recursion case that you hit.

> What I find surprising is that this call of
> wait_reading_process_output is not limited to the process whose
> output queue is full, i.e., the one for which process-send-string
> was actually invoked.

I don't see any reason why it should only wait for output from the
same process.  Once again, this is Emacs's way to wait without
stopping everything else, so waiting for input from any source makes
perfect sense to me.