GNU bug report logs - #60534
28.2; Forbidden reentrant call of Tramp

Previous Next

Full log

View this message in rfc822 format

From: James Thomas <jimjoe <at> gmx.net>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Dima Kogan <dima <at> secretsauce.net>, 49954 <at> debbugs.gnu.org, 60534 <at> debbugs.gnu.org
Subject: bug#60534: 28.2; Forbidden reentrant call of Tramp
Date: Tue, 17 Dec 2024 18:41:53 +0530

Michael Albinus wrote:

> Not so simple.

> ...

> And it isn't clear to me how to keep two connections in sync, if (for
> example) the environment changes in one of the connections. Be it an
> environment variable, the current directory, the availability of a
> temp file, you name it.

And here was I thinking that Tramp was mostly remote-state-less beyond
the handshake...

> There is a serious overhead when opening a new connection, due to the
> handshaking actions.

OK; I misremembered for a moment that it was beyond any ControlPersist.

> But yes, nobody has tried it yet. My preference is to use threads, so
> that one command in a process filter could wait until another command
> in the main thread has finished, as example. But the crucial point is,
> that you must activate threads in the beginning of a connection. When
> you detect, that there is a forbidded reentrant call, it is too late
> to activate threads.

Ah, crucial; but not a blocker, I suppose.

Thank you for the effort in explaining, Michael.

Regards,
James

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.