[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: call-process should not block process filters from running
Date: Mon, 03 Jul 2023 21:51:50 +0300

> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]