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

Previous Next

Full log

Message #19 received at 60534 <at> debbugs.gnu.org (full text, mbox):

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

James Thomas <jimjoe <at> gmx.net> writes:

Hi James,

>> Not so easy to solve. Ideally, remote file name functions initiated in
>> process filters, process sentinels, timers and alike shall wait, until
>> the currently executed remote command has finished. Don't know how to
>> achieve this.
>
> (This may be an ignorant question, but) if that's so, is it possible to
> open a separate connection (perhaps with a ControlPath suffix, and
> ControlPersist-ed) in the place of the "Forbidden reentrant call"?

Not so simple. There is a serious overhead when opening a new
connection, due to the handshaking actions. 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.

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.

> Regards,
> James

Best regards, Michael.

Previous Next

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