Fix for the issue #3646

[dmitry-ganyushin]

It looks like the default for macos and python 3.8+ "spawn" method does not work on macos, switch to "fork" for all situations. https://bugs.python.org/issue33725

[eisenhauer]

I'm curious why you came to the conclusion that spawn doesn't work on macos and you should use fork. At various points in the issue that you link to, and in a followup one at python/cpython#84287, they recommend switching the Python default on macos to Spawn and away from fork because using fork can lead to application crashes. Do we have more recent recommendations than these?

[dmitry-ganyushin]

Discussed in person. A hand test on MacOS was successful; please merge.

[eisenhauer]

I thought the outcome of the discussion was that the older sources (2018-2020 issues) were inconsistent. I.E. Python moved away from 'fork' previously because it didn't work in all situations and recommended spawn, but now we're moving away from spawn because it doesn't work and we're doing back to fork? My impression was that we were going to look for some more recent information on the proper approach to portable use of multiprocessing (or some other similar package) to accomplish the simple thing that this test is trying to do (just create a subprocess to be the other party to communication.)

[anagainaru]

I tend to agree with Greg, the little I read on the internet right now about spawn and fork, it seems spawn is recommended for performance and reliability.

I am also confused how we fix the bug Axel reported in #3646 by changing an example code. Is it your recommendation that they always use fork and not spawn? Shouldn't we make sure our library works regardless of what the users choose to use considering we don't control their codes?

[dmitry-ganyushin]

Continues in #3687