Richard Oudkerk added the comment:
On 03/06/2013 1:02am, spresse1 wrote:
Whats really bugging me is that it remains open and I can't fetch a reference.
If I could do either of these, I'd be happy.
...
Perhaps I really want to be implementing with os.fork(). Sigh, I was trying
to
save
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
Richard Oudkerk added the comment:
On 03/06/2013 3:07pm, spresse1 wrote:
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
spresse1 added the comment:
Oooh, thanks. I'll use that.
But really, this sounds rather fragile.
Absolutely. I concur there is no good way to do this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18120
Richard Oudkerk added the comment:
Actually, you can use gc.get_referents(obj) which returns the direct children
of obj (and is presumably implemented using tp_traverse).
I will close.
--
resolution: - rejected
stage: - committed/rejected
status: open - closed
New submission from spresse1:
[Code demonstrating issue attached]
When overloading multiprocessing.Process and using pipes, a reference to a pipe
spawned in the parent is not properly garbage collected in the child. This
causes the write end of the pipe to be held open with no reference to
Changes by Matthias Lee matthias.a@gmail.com:
--
nosy: +madmaze
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18120
___
___
Python-bugs-list
spresse1 added the comment:
Now also tested with source-built python 3.3.2. Issue still exists, same
example files.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18120
___
Richard Oudkerk added the comment:
The way to deal with this is to pass the write end of the pipe to the child
process so that the child process can explicitly close it -- there is no reason
to expect garbage collection to make this happen automatically.
You don't explain the difference
spresse1 added the comment:
The difference is that nonfunctional.py does not pass the write end of the
parent's pipe to the child. functional.py does, and closes it immediately
after breaking into a new process. This is what you mentioned to me as a
workaround. Corrected code (for
Richard Oudkerk added the comment:
The write end of that pipe goes out of scope and has no references in the
child thread. Therefore, per my understanding, it should be garbage
collected (in the child thread). Where am I wrong about this?
The function which starts the child process by
spresse1 added the comment:
So you're telling me that when I spawn a new child process, I have to deal with
the entirety of my parent process's memory staying around forever? I would
have expected this to call to fork(), which gives the child plenty of chance to
clean up, then call exec()
Richard Oudkerk added the comment:
So you're telling me that when I spawn a new child process, I have to
deal with the entirety of my parent process's memory staying around
forever?
With a copy-on-write implementation of fork() this quite likely to use less
memory than starting a fresh
spresse1 added the comment:
So you're telling me that when I spawn a new child process, I have to
deal with the entirety of my parent process's memory staying around
forever?
With a copy-on-write implementation of fork() this quite likely to use
less memory than starting a fresh process
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
spresse1 added the comment:
I'm actually a nix programmer by trade, so I'm pretty familiar with that
behavior =p However, I'm also used to inheriting some way to refer to these
fds, so that I can close them. Perhaps I've just missed somewhere a call to
ask the process for a list of open
16 matches
Mail list logo
