Hi Vicente,

2017-02-27 14:47 GMT+08:00 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:

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?

I have no idea. Though I think it'd be better to be in the standard as well, but at this moment, it could be a Boost extension.

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?

It saves space, otherwise you have to duplicate the result-storage which the shared-state already has.

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 think of them as building blocks for set_xxx_at_thread_exit.

That is:

set_xxx_at_thread_exit == set_xxx_deferred + notify_deferred_at_thread_exit