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

[sbaugh]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 04/07/2023 21:12, sbaugh@catern.com wrote:
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>> On 03/07/2023 03:02, sbaugh@catern.com wrote:
>>>> Since project-find-regexp can
>>>> take many seconds on large repos, I think this is useful.
>>>> 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?
>>>
>>> Do you have some particular aim related to project-find-regexp?
>>>
>>> Having Emacs interactive and responsive while the search is ongoing
>>> would require a different direction in design.
>>>
>>> Is the goal simply to have other, unrelated code keep running?
>> I merely use project-find-regexp as an example of an important
>> function
>> that uses call-process.  The goal is indeed simply to have other
>> unrelated code keep running.  And to be able to paste in other X
>> clients.  And be able to call project-find-regexp (and other
>> call-process using functions) from a Lisp thread.
>
> Cool.
>
> project-find-regexp also works over Tramp, though. Given Michael's
> objections in the other subthread, do you expect the proposed change
> might break that? If it simply keeps the current limitations (when
> invoked on a remote host), that's probably fine.

There are a number of possible alternative approaches.  One is to change
project-find-regexp to use start-file-process instead of process-file.
This would make project-find-regexp only work with TRAMP backends that
support start-file-process, which is a loss, but there aren't actually
many such backends AFAIK.

It would be nice if Michael would respond to the actual question I
posed, which is "how to avoid this loss".

>> Changing project-find-regexp to use asynchronous processes would be
>> nice, but more work, requiring more design effort.  Running processes
>> synchronously is fine, if it doesn't block unrelated code.
>
> Sure. And there's some expected additional process handling overhead
> after switching to asynchronous calling. Though it would be nice to do
> some experiments, to measure the potential slowdown.

I suppose if project-files has a process-based implementation this is
something we'd want to do anyway, so it can be passed as stdin for
project-find-regexp.  But yes, certainly.