[issue20057] wrong behavior with fork and mmap

2013-12-23 Thread Brett Tiplitz
New submission from Brett Tiplitz: When running the example mmap library (with a slight modification, plus I did not handle all the changes for the 3.3 string handling as the example posted does not work with 3.x) When looking at the subprocess, the spawned process will have all the mmap'd

[issue20057] wrong behavior with fork and mmap

2013-12-23 Thread R. David Murray
R. David Murray added the comment: It seems very likely that this is addressed by PEP 446. Since that is not a behavior change that can be backported, I think this issue should probably be closed as out of date. -- nosy: +haypo, r.david.murray ___

[issue20057] wrong behavior with fork and mmap

2013-12-23 Thread Brett Tiplitz
Brett Tiplitz added the comment: Changing the code to subprocess.call([/bin/ls, -l, /proc/self/fd]) and running this on Python 3.3 does show this as being resolved by the broader fix implemented in PEP 446. It does seem bad that the os.system call remains in place with bad behavior as I

[issue20057] wrong behavior with fork and mmap

2013-12-23 Thread STINNER Victor
STINNER Victor added the comment: This issue is not specific to mmap. Many other functions and libraries may use private inheritable file descriptors. Python 3.4 does not fix the issue for third party libraries. os.system() must be avoided, use subprocess.call() instead. It avoids an useless

[issue20057] wrong behavior with fork and mmap

2013-12-23 Thread Brett Tiplitz
Brett Tiplitz added the comment: Man page currently says as follows: (this does not says it's deprecated or that files have to be closed on exec)... So I'd think some more comments would help. And as mentioned, which a user can close his own fd's, the mmap call creates a special problem