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. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
