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

[Glyph]

Hi Andrew,

Thanks for your work on this.

On Oct 7, 2011, at 1:45 AM, Andrew Mahone wrote:

> 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'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.

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

Sorry that this probably isn't terribly useful feedback.  I really appreciate the time you've put in thus far, and I think 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 :).

> 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
> missed.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20111010/90651d71/attachment.html>