bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64401: 28.1; Desktop restoration


From: Michael Albinus
Subject: bug#64401: 28.1; Desktop restoration
Date: Sun, 02 Jul 2023 11:23:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> From: Michael Albinus <michael.albinus@gmx.de>
>> Cc: Tom Hunt <tom@tomhunt.email>,  64401@debbugs.gnu.org
>> Date: Sun, 02 Jul 2023 10:29:37 +0200
>>
>> > Michael, does Tramp have optional behavior which would abandon attempt
>> > to visit a file if it takes more than some predefined time?
>>
>> No, there isn't. And we cannot implement it for visiting files, because
>> we don't know what would be an acceptable time period for visiting. There
>> might be extremely huge files people try to visit over a slow connection.
>>
>> But what about extending the semantics of `access-file'? It should
>> timeout after a given predefined time. The problem is how to find out
>> this timeout value. For remote files, it depends on the quality of
>> connection (and perhaps on the performance of the remote machine / file
>> system), so we must make it configurable, with reasonable defaults.
>
> Something like that would be useful, yes.

What about

--8<---------------cut here---------------start------------->8---
(defcustom remote-file-name-access-timeout 30
  "Timeout (in seconds) for `access-file'.
This timeout limits the time to check, whether a remote file is
accessible.  `access-file' returns an error after that time.  If
the value is nil, no timeout is used.

For slow connections, it might be useful to increase the value."
  :group 'files
  :version "30.1"
  :type '(choice :tag "Timeout (seconds)" natnum (const nil)))
--8<---------------cut here---------------end--------------->8---

Implementation note: This would be the timeout if the connection is
already established. If there is no connection yet, Tramp would add that
initialization time. Establishing a new connection is always limited by
a reasonable timeout.

>> This timeout might be even useful for local files. Think about hanging
>> mount points and alike.
>
> That could be trickier to implement, since AFAIR we call C APIs for
> that.

OK, so we don't do it.

Best regards, Michael.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]