3 ms·
I can probably. I guess a few prinicpal/staff engineers can too. But doing cross FFI async function invocations and trying to unify runtimes in that fashion is
by Matthias247 6y ago
I can probably. I guess a few prinicpal/staff engineers can too. But doing cross FFI async function invocations and trying to unify runtimes in that fashion is not a thing that people usually do. And it still wouldn't allow you to call QT socket APIs and Netty socket APIs from the same thread.
- pjmlp 6y agoYou missed the point, the languages I mentioned have it as relevant enough to have the async runtime as part of the standard library, instead of leaving it to 3rd parties.
- Matthias247 6y agoC++ coroutines are not more „part of the standard library“ than rusts async support. One might say it might be less, since they arrived so late in c++ lifetime and more Production libraries have been built without them und mind. And again, they don’t make GTK and Qt and boost Asia eventloops interoperable. Even if you implement co_await support for each of them individually
- pjmlp 6y agoThey surely are defined by ISO C++ standard. Like any ISO standard, certain details are expected to be implementation dependent in any ISO C++20 compliant compiler, not missing like on Rust's case.
- dathinab 6y agoYes it's VERY important to differenciate between async/await support (co-rutine) and doing async-io. The problems all come from async-io. "Pure" async/await can be mixed and matched in rust without any problems. But the moment you touch IO (including timeout) a reactor is needed and things get complicated.