[Twisted-Python] Ticket #4519, other possible spawnProcess enhancments

Andrew Mahone andrew.mahone at gmail.com
Fri Oct 7 01:45:12 EDT 2011

I've been working on http://twistedmatrix.com/trac/ticket/4159 and
there has been a bit of discussion on IRC regarding appropriate
interfaces for various things. I think in the long run, the only
python state that setupChild should be allowed to modify should be
args, environment, and the win32 StartupInfo object. This leaves my
own personal use case for it impossible, but I'm working out how to
handle that - special childFDs objects. My proposal so far is that
there be a ProcessFileDescriptor object that inherits from
FileDescriptor. It would add a setup method, which Process would call
in the parent, and separate finishChild and finishParent methods that
would handle things like closing the other end of any pipe-like
objects, and would return a file descriptor - the child would place
this fd in childFDs, the parent would use it for communications with
the child, in the case of objects that wrap pipes or PTYs. I would
also extend the win32 implementation to include some limited support
for childFDs - they could be used to allow the child to inherit
specific file handles as its stdin, stdout, and stderr, instead of
using these exclusively for communications with the parent, so that
redirection to a pipe, to a file, and the building of pipelines could
be accomplished on win32 (I have a project that uses twisted for this
purpose, and I don't use windows, but I would like support to at least
be possible).

I'm seeking comments on whether an extended childFDs interface is the
best way to manipulate the inherited files of the child process, and
whether, if so, fdmap ought to be visible in setupChild at all - in my
opinion, setupChild should be strictly for things like setting the
child PID in an environment variable or as a command line argument,
manipulating scheduler and other parameters external to twisted
itself, and other things of that nature, and the existing childFDs
mechanism should handle any manipulation of file redirection or
inheritance. If there are suggestions on what an extended childFD
object ought to look like, these are welcome as well - I think the
specified methods should handle trivial cases even on platforms
without fork, and should handle nearly anything that really is a file
descriptor on POSIX platforms, but maybe there is something I have
Andrew Mahone
andrew DOT mahone AT gmail DOT com

More information about the Twisted-Python mailing list