[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