3 ms·
Ah! Finally I think I'm getting the distinction, thanks for being patient. I also agree about the ABI issue - explicit callbacks is much simpler. It appears as
by klabb3 5y ago
Ah! Finally I think I'm getting the distinction, thanks for being patient. I also agree about the ABI issue - explicit callbacks is much simpler.
It appears as Go doesn't expose green threads as per your definition for it's FFI though, but rather an even simpler synchronous interface in both directions. This makes it impossible to interface with the event loop, and one must use threads. For Go->C, at least, this should not block the runtime since the Go runtime spins up more threads in case of long running synchronous calls (their version of pre-emption).
- int_19h 5y agoFor an opposite example, consider async/await in C# - you're not restricted to .NET when using it; it also supports e.g. the native async OS APIs in WinRT (which are callback-based on ABI level: https://docs.microsoft.com/en-us/uwp/api/windows.foundation.iasyncinfo https://docs.microsoft.com/en-us/uwp/api/windows.foundation....). Ditto for co_await in C++20. Go's approach leads to an insular ecosystem that tends to reimplement everything, because that's the only way to get this transparent async throughout.