This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Add close() to multiprocessing.Process
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Jim.Jewett, asksol, davin, pitrou, vstinner
Priority: normal Keywords:

Created on 2017-06-08 10:25 by pitrou, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 2010 merged pitrou, 2017-06-08 19:07
Messages (10)
msg295396 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-08 10:25
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?
msg295461 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-08 19:29
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()?
msg295741 - (view) Author: Jim Jewett (Jim.Jewett) * (Python triager) Date: 2017-06-12 03:21
Then why not just call join as part of the default close method?
msg295750 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-12 07:15
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.
msg295783 - (view) Author: Jim Jewett (Jim.Jewett) * (Python triager) Date: 2017-06-12 14:02
Could join be called in a background thread, or even asynchronously?  That
seems like mixing paradigms, but ...

On Jun 12, 2017 3:15 AM, "Antoine Pitrou" <report@bugs.python.org> wrote:

>
> Antoine Pitrou added the comment:
>
> 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.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue30596>
> _______________________________________
>
msg295784 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-12 14:13
I want close() to be deterministic.  So I guess we have two simple possibilities:
1) close() raises if the process is still alive
2) close() calls join() implicitly if the process is still alive
msg295803 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-12 16:46
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.
msg296779 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-24 17:22
New changeset 13e96cc596d158b98996db3fa291086ea4afecd9 by Antoine Pitrou in branch 'master':
Fix bpo-30596: Add close() method to multiprocessing.Process (#2010)
https://github.com/python/cpython/commit/13e96cc596d158b98996db3fa291086ea4afecd9
msg296877 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-06-26 11:47
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.
msg296878 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-06-26 11:48
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.
History
Date User Action Args
2022-04-11 14:58:47adminsetgithub: 74781
2017-06-26 11:48:35pitrousetmessages: + msg296878
2017-06-26 11:47:06vstinnersetnosy: + vstinner
messages: + msg296877
2017-06-24 17:22:45pitrousetstatus: open -> closed
resolution: fixed
stage: needs patch -> resolved
2017-06-24 17:22:25pitrousetmessages: + msg296779
2017-06-12 16:46:16pitrousetmessages: + msg295803
2017-06-12 14:13:06pitrousetmessages: + msg295784
2017-06-12 14:02:03Jim.Jewettsetmessages: + msg295783
2017-06-12 07:15:51pitrousetmessages: + msg295750
2017-06-12 03:21:16Jim.Jewettsetnosy: + Jim.Jewett
messages: + msg295741
2017-06-08 19:29:24pitrousetnosy: + asksol
2017-06-08 19:29:10pitrousetmessages: + msg295461
2017-06-08 19:07:46pitrousetpull_requests: + pull_request2076
2017-06-08 10:25:03pitroucreate