Currently using
Python 3.6.0 (default, Mar  4 2017, 12:32:34) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin

> So, somehow the print() statement is blocking, which I have /no/ idea how to go about debugging. I assume there's a lock /in/ the print statement function call, and I'm probably going to look into wrapping both the print() call and the multiprocessing.Process() call  execution in a single, shared multiprocessing lock, but that
> seems like a very patchwork solution to something that should just work.

I am currently having a similar issue where I get a deadlock to a stdout.flush call (which I assume is called when printing). Flush internally appears to acquire a lock which is getting stuck in the subprocess. 

This is the backtrace I was able to obtain through lldb, showing the waiting for a lock after the flush-call:

* thread #1: tid = 0x77c27d, 0x00007fffe33c9c86 libsystem_kernel.dylib`__psynch_cvwait + 10, stop reason = signal SIGSTOP
    frame #0: 0x00007fffe33c9c86 libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fffe34b396a libsystem_pthread.dylib`_pthread_cond_wait + 712
    frame #2: 0x00000001021ecad8 Python`PyThread_acquire_lock_timed + 256
    frame #3: 0x000000010221cc2f Python`_enter_buffered_busy + 169
    frame #4: 0x000000010221ed36 Python`_io_BufferedWriter_write + 203
    frame #5: 0x000000010215448b Python`_PyCFunction_FastCallDict + 529
    frame #6: 0x000000010211b3f0 Python`_PyObject_FastCallDict + 237
    frame #7: 0x000000010211be9e Python`PyObject_CallMethodObjArgs + 240
    frame #8: 0x000000010222171a Python`_textiowrapper_writeflush + 150
  * frame #9: 0x00000001022224a8 Python`_io_TextIOWrapper_flush + 239


Is there any update on this issue or any solution to avoid deadlocking without wrapping every fork/print/logging call with a multiprocessing (or billiard in my case) lock?