Le 27/02/2017 à 06:24, TONGARI J via Boost-users a écrit :
boost::promise (so does std::promise) only supports set_value/exception and their at_thread_exit variants, while the at_thread_exit variants support deferred notification, but the point to trigger the notification is restricted to thread-exit. This is not sufficient for, e.g. coroutine usage.
This is the same problem as shown in this post: https://www.reddit.com/r/cpp/comments/4ctj2a/visual_studio_2015_update_2_co_...
If you want to write a "correct" adaptor for boost::future, currently you have to use extra storage when you get the return-value from the coroutine, and set the promise until final_suspend is reached.
To efficiently address the problem, we need something like: * promise::set_value_deferred * promise::set_exception_deferred * promise::notify_deferred
Thoughts? Hi,
I don't understand exactly the context where this could be needed. If this is needed for std::promise also, have been there some posts in std-discussions or std--proposals ML or elsewhere for such a proposal? It is weird that Gor has not raised the issue already. IIUC, currently the adaptor can store it already. How the proposed feature would improve the performances? The C++ principle is to don't pay for what you don't use. I believe that the adaptor solution is the good one. Maybe the adaptor would need to store an expected and promise should provide a setting from an expected (but we don't have expected neither on Boost nor the standard). I would like to see a std-proposal discussion so that people that know well the standard thread library can tell what they think. If the feature was really needed: What will be the possible interactions of the deferred settings/notifications and the normal settings? I hope you expect UB if you mix them. Does notify_deferred requires that there should had already a call to set_value_deferred/set_exception_deferred? What would be the expected interactions between two calls to set_value_deferred/set_exception_deferred? UB? What will be the impact on normal futures performances? Does the implementation needs additional flags that must be checked? You can create a github issue to track this possible enhancement. BTW, a PR would be very welcome so that we can experiment with. Best, Vicente