3 ms·

I think fork was a nice solution back when threads weren't common: you just fork, run as many syscalls as you want to modify the running environment, and then d

I think fork was a nice solution back when threads weren't common: you just fork, run as many syscalls as you want to modify the running environment, and then do exec. Unfortunately, with threads, you're now stuck with locks that are potentially held by threads that no longer exist. So you can't call any function that may potentially acquire a lock, like printf, or your program may randomly hang. This feels... inelegant.

Joker_vD 6y ago
After a fork(2) in a multithreaded process returns in the child, the child should call only async-signal-safe functions (see signal-safety(7)) until such time as it calls execve(2) to execute a new program. And since any process can be multithreaded thanks to shared libraries being able to internally do whatever the hell they want to... yeah. Python, for example, in its implementation of subprocess module, had to shift a lot of work into pre-forked parent (such as disabling the GC and allocating all of the memory for exec()'s arguments), to add explicit "call_setsid" argument to reduce the usage of "preexec_fn", and even then, it still has lovely comments such as /* We'll be calling back into Python later so we need to do this. * This call may not be async-signal-safe but neither is calling * back into Python. The user asked us to use hope as a strategy * to avoid deadlock... */ Well, hope is usually not a valid thread-safety strategy, but there is really not much else the Python implementation can do.