<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Andrew,</div><div><br></div><div>Thanks for your work on this.</div><br><div><div>On Oct 7, 2011, at 1:45 AM, Andrew Mahone wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>I've been working on <a href="http://twistedmatrix.com/trac/ticket/4159">http://twistedmatrix.com/trac/ticket/4159</a> and<br>there has been a bit of discussion on IRC regarding appropriate<br>interfaces for various things. I think in the long run, the only<br>python state that setupChild should be allowed to modify should be<br>args, environment, and the win32 StartupInfo object. This leaves my<br>own personal use case for it impossible, but I'm working out how to<br>handle that - special childFDs objects. My proposal so far is that<br>there be a ProcessFileDescriptor object that inherits from<br>FileDescriptor. It would add a setup method, which Process would call<br>in the parent, and separate finishChild and finishParent methods that<br>would handle things like closing the other end of any pipe-like<br>objects, and would return a file descriptor - the child would place<br>this fd in childFDs, the parent would use it for communications with<br>the child, in the case of objects that wrap pipes or PTYs. I would<br>also extend the win32 implementation to include some limited support<br>for childFDs - they could be used to allow the child to inherit<br>specific file handles as its stdin, stdout, and stderr, instead of<br>using these exclusively for communications with the parent, so that<br>redirection to a pipe, to a file, and the building of pipelines could<br>be accomplished on win32 (I have a project that uses twisted for this<br>purpose, and I don't use windows, but I would like support to at least<br>be possible).<br></div></blockquote><div><br></div><div>I've been sitting on this message for a couple of days trying to come up with a good reply. Unfortunately this whole description is phrased in terms of conflicting desires for the implementation, rather than a design strategy or a set of goals or requirements for the API, so my attempted replies have ended up playing whack-a-mole with the concerns one at a time, rather than making an informed critique of the whole proposal.</div><div><br></div><div>Could you try to re-phrase your design here in terms of why we want each of these things, some use-cases, and then maybe spell out the methods and stuff in terms of Python interfaces or classes (or perhaps links to your patch if it already implements what you've described here)?</div><div><br></div><div>Sorry that this probably isn't terribly useful feedback. I really appreciate the time you've put in thus far, and I <i>think</i> I like where you're going with this, I just haven't had time to turn everything inside-out so that I can see it clearly :).</div><div><br></div><blockquote type="cite"><div>I'm seeking comments on whether an extended childFDs interface is the<br>best way to manipulate the inherited files of the child process, and<br>whether, if so, fdmap ought to be visible in setupChild at all - in my<br>opinion, setupChild should be strictly for things like setting the<br>child PID in an environment variable or as a command line argument,<br>manipulating scheduler and other parameters external to twisted<br>itself, and other things of that nature, and the existing childFDs<br>mechanism should handle any manipulation of file redirection or<br>inheritance. If there are suggestions on what an extended childFD<br>object ought to look like, these are welcome as well - I think the<br>specified methods should handle trivial cases even on platforms<br>without fork, and should handle nearly anything that really is a file<br>descriptor on POSIX platforms, but maybe there is something I have<br>missed.</div></blockquote><br></div><br></body></html>