[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?
- Re: call-process should not block process filters from running, Spencer Baugh, 2023/07/01
- Re: call-process should not block process filters from running, Eli Zaretskii, 2023/07/01
- Re: call-process should not block process filters from running, Spencer Baugh, 2023/07/02
- Re: call-process should not block process filters from running, Eli Zaretskii, 2023/07/02
- Re: call-process should not block process filters from running, sbaugh, 2023/07/02
- Re: call-process should not block process filters from running, Po Lu, 2023/07/03
- Re: call-process should not block process filters from running,
sbaugh <=
- Re: call-process should not block process filters from running, Eli Zaretskii, 2023/07/03
- Re: call-process should not block process filters from running, sbaugh, 2023/07/03
- Re: call-process should not block process filters from running, Po Lu, 2023/07/04
- Re: call-process should not block process filters from running, Eli Zaretskii, 2023/07/04
- Re: call-process should not block process filters from running, sbaugh, 2023/07/04
- Re: call-process should not block process filters from running, Michael Albinus, 2023/07/04
- Re: call-process should not block process filters from running, sbaugh, 2023/07/04
- Re: call-process should not block process filters from running, Michael Albinus, 2023/07/05
- Re: call-process should not block process filters from running, Eli Zaretskii, 2023/07/04
- Re: call-process should not block process filters from running, sbaugh, 2023/07/04