Reputation: 21
My question is I have a parent process A, and I set up a daemon thread as a RPC server like TaskRPCServer(Thread). Then I would like to spawn a child process using Python multiprocessing.Process object. Eg: B = Process(), B.start(). Dese B will have the same daemon thread as A? Is there a way that I can force B not have the daemon thread running in A? Because there is some cases that a lot of process will listen to the RPC ports. Or if my design was wrong, how can I do it correctly? Thank you!
Upvotes: 2
Views: 1255
Reputation: 365707
When you fork a child, it starts with only one thread. This is defined by POSIX:1
A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources.
So, your child process will not have the daemon thread. You don't have to do anything to force it not to.
You can test this yourself pretty easily:
import threading
import os
import time
def threadfunc():
while True:
print(os.getpid())
time.sleep(1)
def main():
t = threading.Thread(target=threadfunc)
t.start()
pid = os.fork()
if pid:
print(f'Forked {pid}; sleep time')
time.sleep(5)
else:
print(f'Forked child; sleep time')
time.sleep(5)
main()
If you run this, you'll see something like this:
12345
Forked 12346; sleep time
Forked child; sleep time
12345
12345
12345
Notice that the daemon thread printed 12345, the PID of the parent process, 5 times, and nobody ever printed 12346, the PID of the child process.
But meanwhile, even though it the problem you're asking about doesn't exist, there are sometimes problems mixing fork
and threads, and multiprocessing
gives you a way around those problems, as described in Contexts and start methods.
multiprocessing.set_start_method('forkserver')
guarantees that your child processes are spun up from a clean state as far as threading, mutexes, etc.2 It also protects you from accidentally sharing file handles. (The third option, spawn
, is usually only needed if you want to make sure your code runs the same on Unix and Windows.)
1. This may not be true for some very old Unix platforms, but it will be true for any macOS, Linux, *BSD, etc. that support POSIX threading at least back to 2004, and probably earlier, but I can't find the older POSIX/SUS specs free and legal online anywhere…
2. Besides the problems the POSIX docs warn about, there are murkier problems with things like trying to run a Cocoa main loop while multiprocessing from a background thread.
Upvotes: 3