3 ms·
In recent years, Apple's libc will aggressively create threads to perform background tasks. There is no way to prevent this. Thus, calling fork() on OS X means
by o11c 2y ago
In recent years, Apple's libc will aggressively create threads to perform background tasks. There is no way to prevent this.
Thus, calling fork() on OS X means you can only use async-signal-safe functions, unlike other platforms where abstinence is a choice.
- plorkyeran 2y agoThere’s a lot of system libraries on macOS that’ll spawn threads, but I’ve definitely never seen libc do so.
- olliej 2y agoNo, you can fork, what you can’t do is “fork and then try to keep running after the fork”. That’s never really been a supported model on Darwin, and in recent years with more threading occurring it fails faster than it did in the past. On Darwin there is very little you can safely do in the child after fork(), essentially the only thing guaranteed to work at that point is exec() and a few other basic operations. Again, this has always been the case for fork under Darwin, the only difference is that you are more likely to fail sooner now than 20 years ago. This is also why all documentation says to use posix_spawn: fork +exec is necessarily slower, and can’t really do anything that posix spawn doesn’t.
- o11c 2y ago> can’t really do anything that posix spawn doesn’t. This is blatantly untrue. Probably the most common example is `chdir`, but there's a whole list in signal-safety(7). Using a shim is always a possibility but that's annoying.