[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Change by Terry J. Reedy : -- resolution: -> out of date stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Pascal Chambon added the comment: The latest doc has a quick mention about the fact that daemon is not used in the Unix sens, so it seems fine now B-) https://docs.python.org/3/library/multiprocessing.html?#multiprocessing.Process.daemon """Additionally, these are not Unix daemons or

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Terry J. Reedy added the comment: Is the paragraph "Usually, daemon processes ..." in Pascal's initial post supposed to be a quote from https://docs.python.org/3/library/multiprocessing.html? 'daemon p' is nowhere in the corrent doc and I find nothing like this paragraph. Is this issue

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Tim Peters added the comment: Again, I don't care about orphans. In the usual cases people are running code with no concern about what happens in case of forced termination. The only thing stopping it now is that the code goes out of its way to prevent it (or, alternatively, goes out of its

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Eryk Sun added the comment: > e.g., a Pool worker dies with an assert(!) error if it tries to create > its own Pool for something A daemon process could create a child daemon when the OS can ensure that no orphans are left behind (e.g. call Linux prctl to set PR_SET_PDEATHSIG as SIGKILL).

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Tim Peters added the comment: @Eryk, not me ;-) I find the "daemonic or not?" distinction useless for processes - it just gets in the way at times (e.g., a Pool worker dies with an assert(!) error if it tries to create its own Pool for something). I don't care about orphans either. It's one

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Eryk Sun added the comment: > I've personally found this `multiprocessing` restriction (daemonic > processes can't have children) to be nothing but a pain in the ass To make that reliable on Windows you could create a silent-breakaway, kill-on-close Job object in each process for its daemon

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Tim Peters added the comment: I'll take a crack at these ancient comments ;-) """ daemon The process’s daemon flag, a Boolean value. This must be set before start() is called. The initial value is inherited from the creating process. [1] When a process exits, it attempts to

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Pascal Chambon chambon.pas...@gmail.com added the comment: I've just crossed again the doc of the daemon flag (http://docs.python.org/library/multiprocessing.html), and it's still quite confusing to newcomers. daemon The process’s daemon flag, a Boolean value. This must be set before

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Jesse Noller jnol...@gmail.com added the comment: committed, r73693 on trunk -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5906 ___

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Vaibhav Mallya mally...@umich.edu added the comment: I understand pakal's line of reasoning. The term 'daemon' in the general Unix sense has a specific meaning that is at odds with the multiprocessing module's usage of 'daemon'. Clarification would be useful, I feel, especially if an outright

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Jesse Noller jnol...@gmail.com added the comment: I'm more than familiar with the Unix meaning of Daemon - and the API will *not* be changed or renamed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5906

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Pascal Chambon chambon.pas...@gmail.com added the comment: I guess we all agree on the fact that a renaming of the API would be highly disproportionate ;-) A simple line of warning in the doc, next to the daemonic-related methods, should be sufficient to prevent people like me from wondering

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

New submission from Pascal Chambon chambon.pas...@gmail.com: Usually, daemon processes are processes which got disconnected from their parent process, and work in the background, often under a different user identity. The multiprocessing module has the concept of daemon too, but this time in

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Changes by Benjamin Peterson benja...@python.org: -- assignee: - jnoller nosy: +jnoller ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5906 ___

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Jesse Noller jnol...@gmail.com added the comment: The multiprocessing lib mimics the threading library, and the threading.Thread.daemon has always maintained these are not services/daemons/etc. I don't see that the clarification is needed, but let me think about it. --

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

Pascal Chambon chambon.pas...@gmail.com added the comment: I agree that for someone who discovers the multiprocessing api as a generalization of the threading api, there won't be problems ; I'm just worried about those (like me) who will see daemonic as coming from unix processes, and not the