> 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.