Re: call-process should not block process filters from running

[Eli Zaretskii]

> From: sbaugh@catern.com
> Date: Mon, 03 Jul 2023 13:53:02 -0400
> 
> > I don't recommend doing either from call_process: a lot of existing
> > code relies on Lisp code not running inside calls to that function,
> > and errors inside selection handlers will be signaled even if
> > nothing's wrong with the process being called.
> 
> Right, in the real patch this will be behind a new variable which code
> can let-bind to explicitly opt-in to the new behavior, as Eli suggested.
> So existing code won't see behavior changes.

I'm not sure the new code should call swallow_events, even if
protected by some variable.  We will be giving people a too-long rope
to hang themselves.  It is unreasonable to assume Lisp programmers
will be able to decide when to allow this and when not to, given the
complexities.

Why do we need to jump through all the hoops right at the beginning?
Why not make a small step forward and see if this experiment is more
useful than it is dangerous?  Then we could decide whether to make the
next step, and how.  No one said that pasting into Emacs while a
subprocess runs is the most important capability to enable.  I'd first
make sure the user can type at the keyboard without adverse effects.

Let's not over-engineer this without a sufficient justification.

> > Also, you should at least check that call_process is reentrant: it
> > must be able to handle calls to itself made by any timers or selection
> > handlers that run within the process input loop, with the processes
> > being called completing in any order.
> 
> Hm, good point.  Right now in call_process there's:
> 
>   if (synch_process_pid)
>     error ("call-process invoked recursively");
> 
> So it's at least "safe" to call recursively, since it explicitly errors
> rather than having undefined behavior.  But erroring in this way is
> probably not desirable.
> 
> I can make it re-entrant.  synch_process_pid is itself a global, so
> that's the place to start.
> 
> Eli, your thoughts?  Is this more complicated than you were thinking?

I don't see how it will be more complicated to have a list or array of
PIDs instead of just one value.  This "complication" is nothing
compared to the job of rewriting call-process with all its quirks in
Lisp, even if you ignore the problems and loss of performance we'd
need to sustain to decode and insert the output in Lisp rather than in
C.