[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29735: 27.0.50; It must be possible to suspend all timers
From: |
Stefan Monnier |
Subject: |
bug#29735: 27.0.50; It must be possible to suspend all timers |
Date: |
Tue, 19 Dec 2017 10:58:40 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> If during that time a timer starts, which wants to apply a regular file
> operation (let's say `file-attributes'), the corresponding commands are
> sent to the process related to the just started asynchronous process,
> instead to the working horse *tramp/method host*. This fails, of
> course. Therefore, the start of timers between the both code samples
> must be suppressed.
Hmm... but IIUC the same problem shows up if some random process-filter
or process-sentinel uses, say, file-attributes on that same host, right?
So it's not specific to timers?
>From the description you give, I understand that:
- start-file-process causes the creation of a new underlying ssh process
(that makes sense).
- so from then on, we have 2 (or more) ssh processes on the same host
and the issue is to know which process to use when.
So the problem is to somehow get the "context" of a given call to Tramp,
so as to know which process to use.
Do I understand correctly?
Currently you store which process to use as a "connection-property"
(and it defaults to the "main" process), so basically the "context" is
store in a kind of global variable.
Would it make sense to try and pass that "context" information as
additional arguments instead? Or via dynamically-coped variable?
E.g. any call to file-attributes (or any other file-name-operation)
should always use the main process, right? So the mapping from
connection->process could be stored in a dynamically-scoped var, and
tramp-file-name-handler could let-bind this var to nil?
Stefan