bug#29735: 27.0.50; It must be possible to suspend all timers

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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