4 ms·
Not really a work-around, even with great native thread support and tooling as you dream of (and don't get me wrong, I am all for it), ultra-light "goroutines"
by MetaCosm 13y ago
Not really a work-around, even with great native thread support and tooling as you dream of (and don't get me wrong, I am all for it), ultra-light "goroutines" or "erlang processes" fit a different niche, you are never going to spin up 3+ million OS threads, you absolutely can (and do) in the ultra-light process space.
- comex 13y agoHaving 3 million threads doesn't change the usefulness of being able to call into native syscalls and native libraries that use TLS, locks, etc. It does change the usefulness of native debugger support, since existing debuggers would have a rough time with 3 million threads, but it's not like goroutines currently have any solution to that - Go just uses a GDB script to implement goroutine commands similar to the thread ones. So I think it should absolutely be possible to spin up 3 million OS threads. The kernel needs to change to trust memory mapped into userland to keep track of threads rather than tracking all the data structures itself, and the toolchain needs to support split stacks. This would require a lot of change, but the result would be a lot cleaner than having two strongly overlapping concepts of threads.