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

[Michael Albinus <michael.albinus@gmx.de>]

sbaugh@catern.com writes:

Hi Spencer,

> Here we are talking about switching project-find-regexp to internally
> use start-file-process instead of process-file, since
> project-find-regexp can take non-trivial amounts of time, but retain the
> current synchronous UI.  The benefit would be to not block other Lisp
> from running while project-find-regexp runs, including in filters and
> timers.  But actually running the process underlying project-find-regexp
> asynchronously (e.g., having process filters and sentinels on it) is not
> necessary.

That you can always do, both functions are available. My concern was
rather to call start-file-process inside of process-file.

However, I must claim that Tramp has always hard times when asnychronous
calls, like timers, process sentinels, process filters and alike, invoke
other basic file operations (like file-exists-p) on remote files. These
asynchronous calls could interfer with Tramp's normal workflow on
handling such basic operations, and they are good for the famous ‘Remote
file error: Forbidden reentrant call of Tramp’ error. So I'm always
nervous if such usage patterns apply.

> However, switching from start-file-process to process-file loses support
> for some TRAMP backends.  The question: Is there a way to get the
> benefit (not block other Lisp from running) without the cost (losing
> support for some TRAMP backends)?

Well, checking the different backends (all tramp-*-file-name-handler-alist
constants), there is no Tramp backend which doesn't support process-file
and start-file-process simultaneously.

> Although maybe the answer is to just ensure that every TRAMP backend
> supports start-file-process, since for example project-compile won't
> work with out that also.

That's impossible. Some backends, like tramp-gvfs or tramp-rclone,
simply don't support remote processes.

Best regards, Michael.