[tor-dev] Dormant Mode and pluggable transports

[Alexander Færøy]

Hi,

On Thu, Dec 13, 2018 at 04:15:56PM -0700, David Fifield wrote:
> If transports need to become dormant too, then there needs to be some
> way for tor to tell them to be. Now that https://bugs.torproject.org/28179
> (Handle output from PT processes with the event loop) is almost
> finished, perhaps the stdin/stdout channel would work for it. A request
> to become dormant really does apply to the entire PT process (not just a
> single transport or connection), so it's a good match for a
> process-global channel like stdin. The PT process could respond with a
> "SIGNAL DORMANT" message on its stdout, which would inform tor that the
> PT has understood the request and will try to become dormant.

I've just opened bug #28849 for us to try to figure out how this should
work both for the new process module itself, but especially for the only
consumer of the process module right now: the pluggable transports.

One part of this that especially affects PT's running on Windows is that
we would like to disable the Process I/O timer on Windows (which
currently ticks once a second) when we are in the dormant mode. This
would probably mean that once the stdout or stderr pipe's buffer, in the
PT process, is full writing to stdout/stderr will block which would
effectively be the same result as described in ticket #26360 (which
#28179 as a side-effect also happens to fix).

The easy way out here would of course be to "just" terminate the PT's
when we enter the dormant mode and re-spawn them when we leave the
dormant mode.  If we decide to extend the PT protocol to handle `SIGNAL
DORMANT` would we also need to have a method to inform the PT that it
can start interacting with the rest of the world again?

Would it be bad if `SIGNAL DORMANT` also means that the PT should not
write to stdout/stderr until it's been informed that we are no longer
dormant?  :-)

Cheers,
Alex.

-- 
Alexander Færøy