The existing FAQ entry for multiprocessing blames the problems reported in PYTHON-961 on the getaddrinfo lock, implying that the problem doesn't exist on platforms that don't require the lock, but that's not strictly true.

PyMongo 3.x is not fork safe. The multi-threaded monitoring and shared topology state means that forking is never safe after MongoClient has started to connect because Python Locks are not fork safe. Even without the getaddrinfo lock, if any of PyMongo's Locks are held, or any other Lock used by python internally is held, PyMongo will still deadlock after a fork.

Add a new FAQ entry, "Is PyMongo Fork Safe?", answer the question "No" with a detailed explanation, clean up the multiprocessing FAQ entry to remove the explanations (focus on only the use case), then link the two entries to one another.