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

28 Feb 2017


      Le 27/02/2017 à 11:26, TONGARI J a écrit :
...
Hi Vicente,
2017-02-27 14:47 GMT+08:00 Vicente J. Botet Escriba 
mailto: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
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