[Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)

[Guido van Rossum]

On Wed, Jul 24, 2013 at 2:57 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Wed, 24 Jul 2013 10:56:05 -0700
> Guido van Rossum <guido at python.org> wrote:
>>
>> 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).
>
> So I suppose you mean "change it to False except for
> stdin/stdout/stderr"?

Hm, that's a tricky detail. I expect that on UNIX those are pre-opened
and inherited from the shell, and we should not change their cloexec
status; IIRC on Windows inheritance of the stdin/out/err handles is
guided by a separate flag to CreateProcess().

>> With the new, sane default, all we need instead of PEP 446 is a way to
>> make an FD inheritable after it's been created, which can be a single
>> os.make_inheritable(fd) call that you must apply to the fileno() of
>> the stream or socket object you want inherited (or directly to a FD
>> you created otherwise, e.g. with os.pipe()). On Windows, this should
>> probably only work with os.spawn*(), since otherwise you need *handle*
>> inheritance, not *FD* inheritance, and that's a non-portable concept
>> anyway.
>
> I'm not sure how *fd* inheritance could work without *handle*
> inheritance.
> (since a fd seems to just be a proxy for a handle)

The MS spawn() implementation takes care of this -- I presume they
make the handles inheritable (I think some of the bugs probably refer
to this fact) and then use the "internal" interface to pass the
mapping from FDs to handles to the subprocess.

>> To reduce the need for 3rd party subprocess creation code, we should
>> have better daemon creation code in the stdlib -- I wrote some damn
>> robust code for this purpose in my previous job, but it never saw the
>> light of day.
>
> What do you call "daemon"? An actual Unix-like daemon?

Yeah, a background process with parent PID 1 and not associated with
any terminal group.

-- 
--Guido van Rossum (python.org/~guido)