On 3/18/11 3:29 PM, Ned Deily wrote:
In article<4d838d28.5090...@creativetrax.com>,
Jason Grout<jason-pyt...@creativetrax.com> wrote:
The problem appears to be that multiprocessing sets its workers to have
the daemon flag set to True, which prevents workers from creating child
processes. If I uncomment the line indicated in the code, I can create
child processes and the program works (it prints out the even numbers
from 0 to 18).
It makes me nervous to just change the daemon status of the process like
that, especially when I don't know the reason the workers have
daemon=True to begin with. What is the reasoning behind that decision?
What issues do we need to worry about if we just set the daemon mode
flag like in the above code?
http://docs.python.org/library/multiprocessing.html#multiprocessing.Proce
ss.daemon
"When a process exits, it attempts to terminate all of its daemonic
child processes.
Note that a daemonic process is not allowed to create child processes.
Otherwise a daemonic process would leave its children orphaned if it
gets terminated when its parent process exits. Additionally, these are
not Unix daemons or services, they are normal processes that will be
terminated (and not joined) if non-daemonic processes have exited."
Right; thanks. Let me rephrase my questions:
1. Why is important that the multiprocessing Pool worker processors have
daemon=True (I think this is the same as asking: why is it important
that they be terminated with terminate() rather than join() )?
2. Is it safe for us to reset a Pool worker process to have daemon=False
before starting a subprocess from that worker, like in the code from the
original message?
Thanks,
Jason
--
http://mail.python.org/mailman/listinfo/python-list
