[tor-dev] Dormant Mode and pluggable transports

[David Fifield]

On Fri, Dec 14, 2018 at 04:28:26AM +0100, Alexander Færøy wrote:
> 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?

As I think about it, I'm thinking that terminating the subprocess is
better from a KISS perspective. It's forward-compatible too, in the
sense that you can decide to start sending a "SIGNAL DORMANT" stdin
message in the future. And yes, if there's a "SIGNAL DORMANT" there
should also be a "SIGNAL ACTIVE" or something.

> 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?  :-)

That could be tricky. It may not be worth it.