[pypy-dev] Translating --sandbox -02 python interpreter for windows

[Matti Picus]

Digging around, it seems that close_fds non-support on windows was in 
the original subprocess module,
which was imcluded in stdlib in 2005 (renamed as such from the popen5 
module), and even then
some questioned it's practicality because of race condition problems*
Py3k adds an option to list the fds to be inherited via a pass_fds 
keyword argument, and windows
supports this from Vista onward** however the module does not include 
such support
It would seem the desired patch would actually be to do something like:
- patch cpython's py3k's stdlib's subprocess to support pass_fds on 
windows via UpdateProcThreadAttribute
   and PROC_THREAD_ATTRIBUTE_HANDLE_LIST
- backport this to python 2.7,
- patching sandbox to use pass_fds instead of close_fds

Or just use sandbox on a posix machine :)
Matti

*http://bytes.com/topic/python/answers/26616-pep-324-popen5-new-posix-process-module, 
see Don Cave's comment
**http://blogs.msdn.com/b/oldnewthing/archive/2011/12/16/10248328.aspx
On 9/03/2013 6:40 AM, Armin Rigo wrote:
> Hi Charles,
>
> On Thu, Mar 7, 2013 at 5:42 PM, Charles Roland <mummylauncher at gmail.com> wrote:
>>    File "c:\pypy-2.0-beta1\lib-python\2.7\subprocess.py", line 637, in
>> __init__
>>      raise ValueError("close_fds is not supported on Windows "
>> ValueError: close_fds is not supported on Windows platforms if you redirect
>> stdin/stdout/stderr
> Bah.  It should be obvious from the full traceback: this is because
> sandlib.py calls subprocess.Popen(stdin=..., close_fds=True), and for
> some reason this is not supported on Windows.  Sorry, we cannot be of
> much help, apart from suggesting that you debug it and contribute back
> the fix :-)  It occurs in the pure Python code that attempts to start
> the subprocess, so it should be easy.
>
>
> A bientôt,
>
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> http://mail.python.org/mailman/listinfo/pypy-dev