Re: [Boost-users] [thread] Feature request: set_value/exception with deferred notification (not at_thread_exit)

Subject: Re: [Boost-users] [thread] Feature request: set_value/exception with deferred notification (not at_thread_exit)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-02-27 06:47:36

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_awaitco_return/
>
> 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