[Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)
Guido van Rossum
guido at python.org
Wed Jul 24 20:17:13 CEST 2013
On Wed, Jul 24, 2013 at 11:13 AM, Richard Oudkerk <shibturn at 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)
More information about the Python-Dev
mailing list