I am having an issue with using urllib in a multiprocessing.Process when the package sounddevice (https://github.com/spatialaudio/python-sounddevice) has been already imported.

The sub-process hangs upon calling urllib.request.urlopen (and methods from the requests package too).

1. If the package sounddevice is not imported, things work as expected.
2. If the package sounddevice is imported, but urllib.request.urlopen is called once prior to launching thee sub-process, then things also work as expected.

I have attached a file containing code to reproduce the issue.

I have run this example file in:
- Python 3.7.9 (conda distribution)
- Mac OS X 10.15.7

# Running the code as is reproduces the problem
> python ./test_mp_req.py
Nothing in the queue. Leave.
wait for process to terminate...
finished

# Running the code with either line 8 commented *or* line 32 uncommented
# gives the expected output
> python ./test_mp_req.py
Received https://api.github.com. Send GET request... done.
Received https://www.google.com. Send GET request... done.
https://api.github.com: ok
https://www.google.com: ok
Nothing in the queue. Leave.
wait for process to terminate...
finished

I would assume it’s some interaction between threads and fork. Have you asked the authors of sound device about this?

Thank you very much for the reply! I was indeed hesitating where to post the issue. I have now cross-posted in the sounddevice issue tracker.

https://github.com/spatialaudio/python-sounddevice/issues/302

I'll update the issue if things progress on that side.

The sounddevice is essentially a wrapper around the portaudio library, similar to pyaudio. I have tried the test code with an import of pyaudio rather than sounddevice, but the issue does not happen in that case.

Also note that there are known problems with using the "fork" start method of multiprocessing on macOS. As of Python 3.8, the default start methord on macOS is now "spawn":

https://docs.python.org/3.9/library/multiprocessing.html#contexts-and-start-methods

Try using "spawn" and/or upgrade to a more recent version of Python 3 (3.9.1 is current).

Thanks for the suggestion. I had indeed run into some issues with fork vs spawn before.

I have tested with 3.8.5 and 3.9.1 and the bug doesn't occur with these more recent versions.

Should I leave the bug open since 3.7 is still supported ?

No, let's leave 3.7 alone -- it's in security-fixes-only mode.

Thank you very much for your help!