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-28 21:00:19

Le 27/02/2017 à 11:26, TONGARI J a écrit :
> Hi Vicente,
>
> 2017-02-27 14:47 GMT+08:00 Vicente J. Botet Escriba 
> <vicente.botet_at_[hidden] <mailto:vicente.botet_at_[hidden]>>:
>
>     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
>
Yes, you are right. we need this already.
> I think adding these APIs has no impact on performance, since it's 
> just some tear-down of the original APIs.
> The benefit is that you can now decide when to notify, not just at 
> thread-exit.
>
>     You can create a github issue to track this possible enhancement.
>
>
> Done: https://github.com/boostorg/thread/issues/116

Thanks, I will do it for the next version.

Vicente