> From: Suhail Singh <suhailsingh...@gmail.com> > Cc: Eli Zaretskii <e...@gnu.org>, suhailsingh...@gmail.com, > 73...@debbugs.gnu.org > Date: Tue, 10 Sep 2024 21:05:29 -0400 > > Michael Albinus <michael.albi...@gmx.de> writes: > > > Tramp used a non-zero timeout in the past. This was removed some years > > ago, I don't remember the reason. > > The timeout in tramp-accept-process-output was disabled in commit > 54ef338ba3670415cf47fabc33a92d4904707c7e . The commit mentions > bug#61350 , however, it's not clear (based on briefly skimming the > discussion there) that this change was ever necessary. If not, should > the timeout be reintroduced?
I think Michael just did (see below). > IIUC, we're still actively waiting for the output from the remote host, > but simple not _exclusively_ doing so thanks to the `sit-for'. Is my > understanding correct? When we call sit-for, we yield the CPU for whatever other jobs are waiting, so we don't hog the processor. > If so, isn't there some mechanism to specify a > continuation that's run once the TRAMP process produces output? Such a > mechanism shouldn't require a `sit-for' to yield control. How would that help? Tramp must still wait for the response to proceed with what it does. > In other words, isn't it possible to do both font-locking and getting > the response over ssh concurrently (of the main thread, as well wrt each > other)? Every Lisp program runs in a single thread, so how can that be done in parallel? > If not, are there technical challenges in doing so, or simply that > it's not been implemented (and thus, possibly, we may not know what > the challenges are)? Emacs doesn't support parallel processing, because introducing this into the original single-threaded design is very hard at best, due to a huge global state. We have Lisp threads, but only one thread can run at any given time. > > Pushed to master > > Thank you. I can test this (applied onto 29.4) later in the week along > with the `dired-font-lock-keywords' patch and report back. Thanks.
