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

spresse1 report at bugs.python.org
Mon Jun 3 16:07:01 CEST 2013


spresse1 added the comment:

> I don't see how using os.fork() would make things any easier.  In either 
> case you need to prepare a list of fds which the child process should 
> close before it starts, or alternatively a list of fds *not* to close.

With fork() I control where the processes diverge much more readily.  I could create the pipe in the main process, fork, close unnecessary fds, then call into the class that represents the operation of the subprocess.  (ie: do it the c way).  This way the class never needs to know about pipes it doesnt care about and I can ensure that unnecessary pipes get closed.  So I get the clean, understandable semantics I was after and my pipes get closed.  The only thing I lose is windows interoperability.

I could reimplement the close_all_fds_except() call (in straight python, using os.closerange()).  That seems like a reasonable solution, if a bit of a hack.  However, given that pipes are exposed by multiprocessing, it might make sense to try to get this function incorperated into the main version of it?

I also think that with introspection it would be possible for the subprocessing module to be aware of which file descriptors are still actively referenced.  (ie: 0,1,2 always referenced, introspect through objects in the child to see if they have the file.fileno() method) However, I can't state this as a certainty without going off and actually implementing such a version.  Additionally, I can make absolutely no promises as to the speed of this.  Perhaps, if it functioned, it would be an option one could turn on for cases like mine.

----------

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


More information about the Python-bugs-list mailing list