| msg295396 - (view) |
Author: Antoine Pitrou (pitrou) *  |
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) * |
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) *  |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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. |
|
|