Re:Zero-cost futures in Rust
by soulbadguy on Thursday August 11, 2016 @06:08PM
(#12271973)
Thanks your answer clarifies a lot.
So my question was , as a mechanism to implement async operation how does C++ coroutine compares to this rust library.
From my understanding the C++ committee is pushing for the introduction of coroutine specifically because any library base approach would have the limitation you mentioned. Is that a correct ?
You seems familiar with the C++ committee, do you know a good way to track a feature one is interested in ? I kinda lost track of the coroutine proposal after the 4 revision or Gor paper.
By the beside Visual studio, any other compiler has a working implementation of the current draft ?
Coroutines would still run on top of std::future, it would be Just syntactic sugar to avoid callback hell via then chaining. In same case this might save some allocation as the callback would be a plain pointer to the control block, but that's about it.
I'm not part of the committee nor I attend meetings, but I follow the papers and the public online discussions.
Re:Zero-cost futures in Rust
by soulbadguy on Thursday August 11, 2016 @06:39PM
(#12272153)
From the last Gor paper, coroutine don't need to run on top of the std::future class. The type traits required allows for more computational patters (like generators, agent/actor, full coroutines) etc...
The closest things in the standard to these rust futures, is of course std::future, which currently is very limited as it even lacks chaining and composition. The Concurrency TR (which eventually will be added to the standard, but sadly not for C++17) does provide these features (and more); multiple implementations have been are available for some time (boost, HPX, Folly, and some compiler vendors).
The issues with std::future is that is far from zero cost, as it requires allocation (the control block is dynamically allocated), type erasure (the callback type is not part of the future) and synchronisation (as the promise can be fulfilled from another thread). Efficient implementations of std::future are possible but will never be as fast as what is shown in this rust library.
On the other hand the SeaStar C++ library (I'm in no way involved, just a fan) already provides pretty much the same zero cost futures with a very similar implementation as it doesn't try to follow the standard design.