Hendrik Tews <[email protected]> writes: > Hi,
Hi Hendrik, >> That's not possible. All synchronous remote operations use the *same* >> process. file-attributes, and the operations serving file name >> completion, are synchronous operations. > > OK, but this implies that sentinels, process filters and timers > must not use all the functions listed in section 25.12 "Making > Certain File Names Magic" unless they verify that the respective > path' are not handled by Tramp. I am not sure this is feasible > and I haven't seen such a warning in the elisp manual. "must not use" is too hard. But there could be concurrent situations like you have observed, and this is said in the Tramp manual. >> It is in general not a good idea to invoke synchronous Tramp operations >> in asynchronously running functions like timers, process filters and >> sentinels, event handlers. The Tramp manual mentions this in the FAQ >> section. > > I haven't found this point in the manual. I only found that the > filter or sentinel, which is involved when the "reentrant call" > error is signaled, should be fixed. I assumed the fix is to tell > Tramp to use a different connection buffer or to acquire some > lock, that serializes all synchronous operations. It is not explicitly phrased in the manual, yes. Perhaps this shall be improved. > Instead of throwing the error, with-tramp-locked-connection could > wait with sit-for or accept-process-output until PROC is not > locked. No. Tramp is a dumb library, and it runs whatever it is said to run. It shouldn't add own intelligence, this is always good for trouble. Such a locking mechanism shall be added by the caller. Two years ago, I've started to make Tramp thread-safe. By this, Emacs threads could be used for remote file operations. This wouldn't improve performance (there could be only one Emacs thread at a given time), but its mutex mechanism could avoid the reentrant Tramp function calls. Unfortunately, this project is stalled due to some blocking problems, mainly bug#25214. This is not a Tramp specific problem, but a general one. I have no idea, how to continue until this is solved. > Best regards, > > Hendrik Best regards, Michael.
