[Twisted-Python] Ticket #4519, other possible spawnProcess enhancments
radix at twistedmatrix.com
Mon Oct 10 15:18:46 EDT 2011
Software Development Methodology!!!!
1. Use Cases
3. Proposed Technical Design
Bonus points if you include Visio diagrams!!!!
Top-posted for genuine experience!!!!
On Mon, Oct 10, 2011 at 9:53 AM, Glyph <glyph at twistedmatrix.com> wrote:
> 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
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Twisted-Python