New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add close() to multiprocessing.Process #74781
Comments
multiprocessing.Process (actually, the _popen object attached to it) has a GC-based finalizer to release system resources (such as fds). However, it would be nice to be able to release those resources in a timely manner. Adding a close() method would let users do that. What do you think? |
close() wouldn't terminate the underlying process, so the process would still exist (and wouldn't easily be stoppable from Python anymore) if you were to call close() before terminate() or join(). Perhaps we should instead mandate people call join() before close()? |
Then why not just call join as part of the default close method? |
That's a good question. close() methods on other objects tend to avoid taking an infinite amount of time :-) But then, Process objects are different enough that they don't need to follow that rule. |
Could join be called in a background thread, or even asynchronously? That On Jun 12, 2017 3:15 AM, "Antoine Pitrou" <report@bugs.python.org> wrote:
|
I want close() to be deterministic. So I guess we have two simple possibilities:
|
I've decided it's better to raise a ValueError if the child process hasn't stopped yet. After all, join() alone may have no effect: often you want to send the process a signal (a literal signal in UNIX terms, or a figurative signal such as write something on a socket, etc.) to ask it to terminate gently. I'm gonna update the PR soon. |
Since the object now has a close() method, would it make sense to emit a ResourceWarning if it's not closed explicitly? As I did recently in subprocess.Popen destructor. |
I don't think so. It is ok to let the GC delete the resources by itself. close() is just there for people who want to ensure whatever small amount of resources (a file descriptor, mostly) are released timely. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: