[RPC] Make RPC fork safe on macOS?

[eqy]

(Observed On macOS 10.14.3)
RPC seems to work fine when it is just a single process (e.g., in simple test cases such as android_rpc_test.py).

We currently use RPC for AutoTVM tuning, and we fork a different process for each measurement for parallelism/robustness. However, this seems to break with something like

objc[17591]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead.

export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES seems to be a workaround; found randomly here, but while it works (partially) for a simple Pool -> map wrapping of RPC, tuning still crashes with a segmentation fault in get_addr_info.

[eqy]

CC @antinucleon @tqchen

[ajtulloch]

Yeah, we (@hlu1 @antinucleon) noticed some bizarre issues in the new OS X version after the Facetime bug update (including a segfault deep inside the OS X networking stack). I wonder if CPython needs this block to be fixed: https://github.com/python/cpython/blob/8b9dbc017a190d13f717e714630d620adb7c7ac2/Modules/socketmodule.c#L220-L227.

Alternatively, passing numerical addresses directly avoids going into getaddrinfo(..), e.g. https://github.com/python/cpython/blob/8b9dbc017a190d13f717e714630d620adb7c7ac2/Modules/socketmodule.c#L1097-L1125.

[ajtulloch]

@eqy do you have a simple local-only reproduction that works? IIRC setting LocalExecutor(..., do_fork=False) was an alternative workaround in this case, but it would good to have a local-only repro so we can a) send a bug to Apple, b) see if these proposed fixes actually fix the problem that you're observing.