This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sbt
Recipients Arfrever, DLitz, aliles, amaury.forgeotdarc, asvetlov, christian.heimes, georg.brandl, grahamd, gregory.p.smith, jcea, lemburg, neologix, pitrou, sbt, twouters, vstinner
Date 2013-11-01.12:49:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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().

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?
Date User Action Args
2013-11-01 12:49:46sbtsetrecipients: + sbt, lemburg, twouters, georg.brandl, gregory.p.smith, jcea, amaury.forgeotdarc, pitrou, vstinner, christian.heimes, grahamd, Arfrever, asvetlov, neologix, aliles, DLitz
2013-11-01 12:49:46sbtsetmessageid: <>
2013-11-01 12:49:46sbtlinkissue16500 messages
2013-11-01 12:49:46sbtcreate