On Wed, Jul 24, 2013 at 11:13 AM, Richard Oudkerk <shibt...@gmail.com> wrote: >> Wow. Indeed you can -- I just tested this myself. How is this >> accomplished? I guess the CRT has a backchannel to talk to itself when >> it creates a process using spawn*? > > CreateProcess() takes a STARTUPINFO argument with undocumented fields > cbReserved2, lpReserved2. They are used to pass an array of fds.
Does it also inherit sockets (which take up a different namespace than regular FDs in CRT, unlike UNIX)? >> But I'm also ready to propose that all this is such a mess that we >> >> *should* change the default fd/handle inheritance to False, *across >> platforms*, and damn the torpedoes -- i.e. accept breaking all >> existing 3rd party UNIX code for subprocess creation that bypasses the >> subprocess module, as well as breaking uses of os.spawn*() on both >> platforms that depend on FD inheritance beyond stdin/stdout/stderr). > > +1 Thanks! This was a difficult conclusion to come to. "Damn the torpedoes" is occasionally a nice meme. :-( >> We can fix multiprocessing any anything else in the stdlib that this >> breaks, I presume. > > In the experimental branch of multiprocessing, child processes no longer > inherit unnecessary handles. And if we default individual handles to uninheritable, we can presumably fix the ones that multiprocessing creates with the express purpose of being inherited easily. (If it even uses that -- I haven't read the source code, maybe it uses named pipes? :-) -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com