I am pretty sure this is another instance of issue 6721.

multiprocessing is forking a new process and if that happens while the other thread is holding the lock for stdout, the process will deadlock because the lock state is replicated in the subprocess while the thread that is supposed unlock it isn't (even if you remove all prints, the deadlock will happen on a stdout flush).

Attaching a gdb to a hung subprocess confirms that it is waiting for a lock in the bufferedio module.

I've reproduced this on Python trunk running on Linux (using pthreads) and can confirm that the patch attached to issue 6721 fixes it.

I'm also attaching a shorter test case that omits unused code from the original example.