Comment by _0w8t
4 years ago
Windows approach is not the only alternative. Simply provide API to create a process in a suspended state, then adjust its properties based on pid/handle and then start the process execution.
4 years ago
Windows approach is not the only alternative. Simply provide API to create a process in a suspended state, then adjust its properties based on pid/handle and then start the process execution.
A huge number of tricky thread problems go away if the child thread is blocked at startup, and allowed to run only after the parent allows it. To retrofit this, it is easiest to lock a mutex before spawning and have the child block on that. Then the parent unlocks it to let the child run.
I think shared libraries can spawn threads on their load/init phase that you don't know about. Then you are hosed but you only know about it due to sporadic weird problems, that if you restart on failure, e.g. a pre-forked worker scenario, you might never even really care about.
I always felt that the way to create new processes and new threads should initially start the same. A new process is simply a thread that after creation does a syscall to isolate itself from the other thread and receive a unique copy of all resources.
This could also solve the issue with forking from multithreaded programs since we can ensure we own all shared resources when we isolate our thread, to effectively thus become a new process.
So instead of fork we have clone/isolate.
A new thread can also of course immediately suspend itself, allow other threads to work on it's data in some way, who then give it a signal to resume itself and then execute if need be.