> For the Python implementation, the GIL is not enough to
> ensure the atomicity of a process creation. That's why 
> _posixsubprocess was created. I suppose that other parts 
> of subprocess are not atomic and a lock is required to
> ensure that the creation of subprocess is atomic.
Both _posixsubprocess.fork_process and _posixsubprocess.cloexec_pipe (without HAVE_PIPE2) hold the GIL. They can't be running at the same time, so in regards to each other, they will be atomic. Or at least that's the idea. You don't need a separate lock when the GIL is already held. Neither a lock nor the GIL make the operation to be atomic (e.g. if someone forks from multiprocessing, the effect might be different, though os.fork() also holds the GIL and I think multiprocessing uses it).

The idea of _posixsubprocess is that fork() isn't thread-safe, because Python might call malloc() or free() in the child, which might be currently locked by another thread, which might cause the child to hang. Nothing to do with atomicity.

> Can you add a comment to explain why you can release the 
> GIL here? (because the operation is atomic)

I release the GIL because I copy-pasted the code from os.pipe(). It makes sense that pipe() and pipe2() are called in the same way. In the other implementation it is held to (ab)use it to avoid the race, but there's no need to hold it here because pipe2() *is* atomic.