[issue18120] multiprocessing: garbage collector fails to GC Pipe() end when spawning child process

[Richard Oudkerk]

Richard Oudkerk added the comment:

> What I'm still trying to grasp is why Python explicitly leaves the
> parent processes info around in the child.  It seems like there is
> no benefit (besides, perhaps, speed) and that this choice leads to
> non-intuitive behavior - like this.

The Windows implementation does not use fork() but still exhibits the 
same behaviour in this respect (except in the experimental branch 
mentioned before).  The real issue is that fds/handles will get 
inherited by the child process unless you explicitly close them. 
(Actually on Windows you need to find a way to inject specific handles 
from the parent to child process).

The behaviour you call non-intuitive is natural to someone used to using 
fork() and pipes on Unix.  multiprocessing really started as a 
cross-platform work-around for the lack of fork() on Windows.

Using fork() is also a lot more flexible: many things that work fine on 
Unix will not work correctly on Windows because of pickle-issues.

The main problem with fork() is that forking a process with multiple 
threads can be problematic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18120>
_______________________________________