emacs-devel
[Top][All Lists]
Advanced

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

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


From: sbaugh
Subject: Re: call-process should not block process filters from running
Date: Mon, 03 Jul 2023 13:53:02 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Po Lu <luangruo@yahoo.com> writes:
> sbaugh@catern.com writes:
>> However, my other main test case/use case, being able to paste while
>> Emacs is in call-process, doesn't work with this change.  Any idea on
>> how to make that work?
>
> By entering the command loop or by calling `process_special_events'
> every time wait_reading_process_input returns.

Thanks, with this patch:

diff --git a/src/callproc.c b/src/callproc.c
index 6f3d4fad9be..2135308c2c5 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -778,6 +778,9 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int 
filefd,
              nread += this_read;
              total_read += this_read;
 
+             wait_reading_process_output(-1, -1, 0, display_on_the_fly,
+                                         NULL, NULL, 0);
+             swallow_events(display_on_the_fly);
              if (display_on_the_fly)
                break;
            }

I can paste while Emacs is blocked in call_process, awesome.  (although
with some lag - but it's good enough for now)

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

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




reply via email to

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