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.