[issue30596] Add close() to multiprocessing.Process

Antoine Pitrou added the comment: 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. -- _

[issue30596] Add close() to multiprocessing.Process

STINNER Victor added the comment: 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. -- nosy: +haypo ___ Python tracker

[issue30596] Add close() to multiprocessing.Process

Antoine Pitrou added the comment: 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 -- ___

[issue30596] Add close() to multiprocessing.Process

Changes by Antoine Pitrou : -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker ___ ___

[issue30596] Add close() to multiprocessing.Process

Antoine Pitrou added the comment: 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

[issue30596] Add close() to multiprocessing.Process

Antoine Pitrou added the comment: 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 -- ___ Python tracker

[issue30596] Add close() to multiprocessing.Process

Jim Jewett added the comment: 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" wrote: > > Antoine Pitrou added the comment: > > That's a good question. close() methods on other objects ten

[issue30596] Add close() to multiprocessing.Process

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 t

[issue30596] Add close() to multiprocessing.Process

Jim Jewett added the comment: Then why not just call join as part of the default close method? -- nosy: +Jim.Jewett ___ Python tracker ___ ___

[issue30596] Add close() to multiprocessing.Process

Antoine Pitrou added the comment: 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 clo

[issue30596] Add close() to multiprocessing.Process

Changes by Antoine Pitrou : -- nosy: +asksol ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue30596] Add close() to multiprocessing.Process

Changes by Antoine Pitrou : -- pull_requests: +2076 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue30596] Add close() to multiprocessing.Process

New submission from Antoine Pitrou: 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 u