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: TONGARI J (tongari95_at_[hidden])
Date: 2017-02-27 10:26:58

Hi Vicente,

2017-02-27 14:47 GMT+08:00 Vicente J. Botet Escriba <
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

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