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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Users mailing list
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:

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?

_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Users mailing list
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
_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Users mailing list
Hi Vicente,

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


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Boost - Users mailing list
Le 27/02/2017 à 11:26, TONGARI J a écrit :
Hi Vicente,

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

Thanks, I will do it for the next version.


Vicente


_______________________________________________
Boost-users mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Loading...