11 ms·
Alef (arguably one of the antecedent of Go) had stackful couroutines/fibers yet it could have had such a seamless FFI to the standard C API/ABI. The plan9 libt
by dfawcus 1y ago
Alef (arguably one of the antecedent of Go) had stackful couroutines/fibers yet it could have had such a seamless FFI to the standard C API/ABI.
The plan9 libthread (which reimplemented the Alef concurrency model for C) did have seamless use of the C API/ABI.
The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine. It was then easy to share data as the CSP model (with channels) worked between both coroutines, threads, and coroutines within a thread.
So if one wishes to use stackful coroutines, and still have that seamless compatibility, an approach mixing the Go and Alef approaches would seem necessary. i.e. the Go migrating coroutines as a default, but with the option to use Alef like thread bound coroutines when necessary.
- zozbot234 1y ago> The mechanism was that it had threads and coroutines, a function needing to make use of the C API in a seamless manner would simply run as a thread rather than a coroutine. This reintroduces the colored functions that we were trying to get away from in the first place, by adopting stackful coroutines/fibers. Why not use async at that point? I can understand that Alef didn't, because stackless mechanisms were not well understood at the time. But it's plausible that we can do better.