> On Jan 29, 2025, at 9:58 AM, Michael Albinus <michael.albi...@gmx.de> wrote: > > JD Smith <jdtsm...@gmail.com <mailto:jdtsm...@gmail.com>> writes: > > Hi, > >> One way around all this I've found: setup `direct-async' as we >> discussed (full, no "-t -t"), then, upon startup, collect the PID from >> the process itself (e.g., in python: import os; os.getpid()). Set >> this PID into the process' plist as 'remote-pid. > > How do you do this in general? The idea of direct async processes is to > fire the respective command, and forget it. No further handling. It is > intended for speed-up.
A side effect of that speed up is cutting out the PTY middle-man which interferes with the transfer of binary data. Though I of course don't mind a speedup, that's my primary interest in using it. > And we cannot assume that there is python installed on the remote side, > or that a shell is running (which tells us $$). If you have a proper > patch for Tramp how to retrieve the remote-pid, pls show. It would be application specific, not a general TRAMP setting. In my case, the remote application itself (iPython) would send a message reporting its own PID, and my package code would read that PID and set it into the process property. I don't think TRAMP would need to do anything special (other than not inhibiting this usage for direct-async connections). Since my package requires an (i)ipython executable to exist on the remote side, if it fails to find one, well that's a user error. > Until we find a way for sending signals to the remote direct async > process, we must point to the non-direct case. The normal non-direct ControlMaster side-channel commands like "kill -2" seem to work just fine for direct-async. TRAMP just needs a 'remote-pid. >> Good news: this actually works well for signals! Unfortunately >> `tramp-interrupt-process' causes problems here, due to this unusual >> bit at the end: >> >> ;; Wait, until the process has disappeared. If it doesn't, >> ;; fall back to the default implementation. >> (while (tramp-accept-process-output proc)) >> (not (process-live-p proc))))) >> >> I must admit I don't understand this code. If the process remains >> alive after the interruption is sent, the "default implementation" is >> subsequently employed, which, as mentioned above, kills the SSH >> process itself. Long-lived processes should _not_ necessarily exit >> upon interrupt. Many of them, e.g. the Python REPL, specifically >> catch SIGINT and use that to interrupt their own running commands. >> >> I wonder if this behavior can be gated behind a custom variable, like >> `tramp-interrupt-ends-process'. So something like: >> >> ;; If we expect interrupt to end the process, wait until it >> ;; has disappeared. If it doesn't, fall back to the default >> ;; implementation. >> (if tramp-interrupt-ends-process >> (progn (while (tramp-accept-process-output proc)) >> (not (process-live-p proc))) >> t))))) ; handled > > Don't know yet. That will be a longer way to go. But first I must > recover from my recent health malaises. Take your time and best wishes for a speedy recovery. In the meantime I will experiment with substituting my own interrupt function which handles this more simply, just sending over a kill -2. Will update with any progress. Thanks again for your tireless work on TRAMP. Hope you feel better soon!
