En Thu, 18 Dec 2008 08:35:58 -0200, Aaron Brady <castiro...@gmail.com> escribió:
On Dec 17, 7:16 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar> wrote:En Wed, 17 Dec 2008 22:46:32 -0200, Aaron Brady <castiro...@gmail.com> escribió: > On Dec 17, 5:05 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar> > wrote: >> En Wed, 17 Dec 2008 12:21:38 -0200, Jeremy Sanders >> <jeremy+complangpyt...@jeremysanders.net> escribió: >> > It would be nice if Python created pipes that are properly >> inheritable by >> > default by child processes, as they're mostly used for IPC. >> I'd say it is a bug in os.pipe implementation; they should be >> inheritable >> by default, as in posix (after all, the code is in "posixmodule.c"). > The code looks like this: > ok = CreatePipe(&read, &write, NULL, 0); > Py_END_ALLOW_THREADS > if (!ok) > return win32_error("CreatePipe", NULL); > read_fd = _open_osfhandle((Py_intptr_t)read, 0); > write_fd = _open_osfhandle((Py_intptr_t)write, 1); > 'If lpPipeAttributes is NULL, the handle cannot be inherited.' You > could populate a 'SECURITY_ATTRIBUTES' structure, or call > DuplicateHandle on both of them. > A patch would look like this: > SECURITY_ATTRIBUTES sattribs; > sattribs.nLength = sizeof(sattribs); > sattribs.lpSecurityDescriptor = NULL; > sattribs.bInheritHandle = TRUE; > ok = CreatePipe(&read, &write, &sattribs, 0); Yes, that's exactly how os.popen does it (in posixmodule.c) > This still doesn't answer whether the file descriptor return by > '_open_osfhandle' can be inherited too. It doesn't matter. The OS only cares about file handles, not C RTL structures. -- Gabriel GenellinaAh, I see. Was it an executive decision about what is Pythonic, or just a bug? Do you think the patch would be accepted? I probably ought to mimic a small Python embedding to see if it needs anything else.
I don't know - I guess someone (years ago) blindly just replaced the pipe() system call by a CreatePipe call without further analysis. This is how I would summarize the issue: Pros (of changing os.pipe() to return inheritable pipes): - it isn't explicitely documented whether os.pipe() returns inheritable pipes or not, so both versions are "right" according to the documentation. - if someone relies on pipes being non-inheritable on Windows, that is undocumented behaviour, and Python has the right to change it. - the change would improve POSIX compatibility, it mimics what os.pipe() does on those OS. - inheritable pipes are less surprising for guys coming from other OS - inheritable pipes are a lot more useful than non-inheritable ones when doing IPC (probably its main usage). Cons: - os.pipe has behaved that way since long time ago. - some programs *might* break, if they relied on pipes being non-inheritable on Windows, even if that was undocumented behaviour. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
