3 ms·
It's a cleaner design, but I don't think it addresses the core of the issue. You can still have say a "multi-threaded program" with a global mutex (the threads
by chubot 8y ago
It's a cleaner design, but I don't think it addresses the core of the issue.
You can still have say a "multi-threaded program" with a global mutex (the threads are created with RFMEM), and then when you want to fork (without RFMEM), you can be prone to deadlocks.
I guess the thread library has channels, and that doesn't happen? But as far as I know there are still mutexes in Go, and I would presume plan 9.
Go also has problems forking since it has a multi-threaded runtime. It only exposes os.ForkExec(), not os.Fork() and os.Execv().
- MisterTea 8y ago> I guess the thread library has channels, and that doesn't happen? But as far as I know there are still mutexes in Go, and I would presume plan 9. It does! Have a look at the thread man page: http://man.9front.org/2/thread http://man.9front.org/2/thread It's pretty much a wrapper/helper library built around rfork.
- dis-sys 8y ago> Go also has problems forking since it has a multi-threaded runtime. It only exposes os.ForkExec(), not os.Fork() and os.Execv(). true, and this is causing lots of headache for those who want to implement concurrent snapshotting using fork in Go.
- dullgiulio 8y agoI thought this was a solved issue? https://github.com/golang/go/issues/20676 https://github.com/golang/go/issues/20676