[coroutine2] Difference between coroutine and coroutine2
Are boost::coroutines::symmetric_coroutine<> and boost::coroutines::asymmetric_coroutine<> part of the coroutine library or coroutine2 library. Besides being C++14-only, in what ways does coroutine2 differ from coroutine? -- Aaron Levy aaron.levy@yandex.com
2015-06-21 12:19 GMT+02:00 Aaron Levy <aaron.levy@yandex.com>:
Are boost::coroutines::symmetric_coroutine<> and boost::coroutines::asymmetric_coroutine<> part of the coroutine library or coroutine2 library. Besides being C++14-only, in what ways does coroutine2 differ from coroutine?
Coroutine2 provides only boost::coroutines2::asymmetric_coroutine<> (boost::coroutines2::coroutine<> is a typedef of the previous one). Symmetric_coroutine<> (introduced for boost.fiber) is not implemented because its functionality/semantic is better represented by class boost::context::execution_context (part of boost.context). Class execution_context is used as building block (implementation) of boost::coroutines2::asymmetric_coroutine<> - the code becomes cleaner.
On June 21, 2015 6:53:12 AM EDT, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2015-06-21 12:19 GMT+02:00 Aaron Levy <aaron.levy@yandex.com>:
Are boost::coroutines::symmetric_coroutine<> and boost::coroutines::asymmetric_coroutine<> part of the coroutine library or coroutine2 library. Besides being C++14-only, in what ways does coroutine2 differ from coroutine?
Coroutine2 provides only boost::coroutines2::asymmetric_coroutine<> (boost::coroutines2::coroutine<> is a typedef of the previous one). Symmetric_coroutine<> (introduced for boost.fiber) is not implemented because its functionality/semantic is better represented by class boost::context::execution_context (part of boost.context). Class execution_context is used as building block (implementation) of boost::coroutines2::asymmetric_coroutine<> - the code becomes cleaner.
If there's only one kind of coroutine in coroutine2, why isn't it just named "coroutine"? ___ Rob (Sent from my portable computation engine)
2015-06-22 10:29 GMT+02:00 Rob Stewart <rob.stewart@verizon.net>:
If there's only one kind of coroutine in coroutine2, why isn't it just named "coroutine"?
asymmetric_coroutine<> describes the coroutine type (assymetric transfer of execution control), but coroutine.hpp contains: template< typename T > using coroutine = asymmetric_coroutine< T >; so you could use coroutine<> if desired.
On June 22, 2015 4:41:05 AM EDT, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2015-06-22 10:29 GMT+02:00 Rob Stewart <rob.stewart@verizon.net>:
If there's only one kind of coroutine in coroutine2, why isn't it just named "coroutine"?
asymmetric_coroutine<> describes the coroutine type (assymetric transfer of execution control),
With only one kind, the documentation already describes how it behaves. Having asymmetric_coroutine suggests other variations are expected in the future.
but coroutine.hpp contains:
template< typename T > using coroutine = asymmetric_coroutine< T >;
so you could use coroutine<> if desired.
If you think asymmetric_coroutine is necessary, and clearly I do not, you should reverse those. That is, asymmetric_coroutine should be the alias. ___ Rob (Sent from my portable computation engine)
Le 22/06/15 11:10, Rob Stewart a écrit :
On June 22, 2015 4:41:05 AM EDT, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2015-06-22 10:29 GMT+02:00 Rob Stewart <rob.stewart@verizon.net>:
If there's only one kind of coroutine in coroutine2, why isn't it just named "coroutine"? asymmetric_coroutine<> describes the coroutine type (assymetric transfer of execution control), With only one kind, the documentation already describes how it behaves. Having asymmetric_coroutine suggests other variations are expected in the future.
but coroutine.hpp contains:
template< typename T > using coroutine = asymmetric_coroutine< T >;
so you could use coroutine<> if desired. If you think asymmetric_coroutine is necessary, and clearly I do not, you should reverse those. That is, asymmetric_coroutine should be the alias.
I don't agree. asymmetric_coroutine is the correct term. This let us to add again symmetric_coroutine if the need comeback. Vicente
On June 22, 2015 1:13:54 PM EDT, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
Le 22/06/15 11:10, Rob Stewart a écrit :
On June 22, 2015 4:41:05 AM EDT, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2015-06-22 10:29 GMT+02:00 Rob Stewart <rob.stewart@verizon.net>:
If there's only one kind of coroutine in coroutine2, why isn't it just named "coroutine"? asymmetric_coroutine<> describes the coroutine type (assymetric transfer of execution control), With only one kind, the documentation already describes how it behaves. Having asymmetric_coroutine suggests other variations are expected in the future.
but coroutine.hpp contains:
template< typename T > using coroutine = asymmetric_coroutine< T >;
so you could use coroutine<> if desired. If you think asymmetric_coroutine is necessary, and clearly I do not, you should reverse those. That is, asymmetric_coroutine should be the alias.
I don't agree. asymmetric_coroutine is the correct term. This let us to add again symmetric_coroutine if the need comeback.
If that must remain a possibility, then there should be no "coroutine" alias and the header should be asymmetric_coroutine.hpp. If symmetric_coroutine was removed for good reason, does that reason not preclude its return? I don't have that answer. I'm just inferring from the result. ___ Rob (Sent from my portable computation engine)
On Tue, Jun 23, 2015 at 11:44 AM, Rob Stewart <rob.stewart@verizon.net> wrote:
On June 22, 2015 1:13:54 PM EDT, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
Le 22/06/15 11:10, Rob Stewart a écrit :
On June 22, 2015 4:41:05 AM EDT, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2015-06-22 10:29 GMT+02:00 Rob Stewart <rob.stewart@verizon.net>:
If there's only one kind of coroutine in coroutine2, why isn't it just named "coroutine"? asymmetric_coroutine<> describes the coroutine type (assymetric transfer of execution control), With only one kind, the documentation already describes how it behaves. Having asymmetric_coroutine suggests other variations are expected in the future.
but coroutine.hpp contains:
template< typename T > using coroutine = asymmetric_coroutine< T >;
so you could use coroutine<> if desired. If you think asymmetric_coroutine is necessary, and clearly I do not, you should reverse those. That is, asymmetric_coroutine should be the alias.
I don't agree. asymmetric_coroutine is the correct term. This let us to add again symmetric_coroutine if the need comeback.
If that must remain a possibility, then there should be no "coroutine" alias and the header should be asymmetric_coroutine.hpp.
If symmetric_coroutine was removed for good reason, does that reason not preclude its return? I don't have that answer. I'm just inferring from the result.
I share Rob's confusion. If the 'coroutine' alias is just some sort of a default coroutine then at least its naming is inappropriate (I would suggest something like 'default_coroutine', if such alias is at all needed). If the library does not plan to add a symmetric_coroutine then I see no point in the 'asymmetric' qualification.
participants (5)
-
Aaron Levy -
Andrey Semashev -
Oliver Kowalke -
Rob Stewart -
Vicente J. Botet Escriba