Charles-François Natali added the comment: > Given PEP 446 (fds are now CLOEXEC by default) I prepared an updated patch > where the fork lock is undocumented and subprocess no longer uses the fork > lock. (I did not want to encourage the mixing of threads with fork() without > exec() by exposing the fork lock just for that case.) > > But I found that a test for the leaking of fds to a subprocess started with > closefds=False was somewhat regularly failing because the creation of CLOEXEC > pipe fds is not atomic -- the GIL is not held while calling pipe().
Was it on Linux? If yes, was it on an old kernel/libc? (I just want to make sure that pipe2() is indeed used if available). > It seems that PEP 446 does not really make the fork lock redundant for > processes started using fork+exec. > > So now I don't know whether the fork lock should be made public. Thoughts? IMO it should be kept private for now: I think it's really only useful in some corner cases, and if it turns out to be useful, we can expose it later. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16500> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
