------=_Part_490_1709592339.1433588840213
Content-Type: multipart/alternative;
 boundary="----=_Part_491_1934728360.1433588840213"

------=_Part_491_1934728360.1433588840213
Content-Type: text/plain; charset=UTF-8

Hello All!

Boost.Asio has macro-based emulation of Stackless Coroutines:
http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/overview/core/coroutine.html
http://blog.think-async.com/2010/03/potted-guide-to-stackless-coroutines.html

In short, user of such coroutines should manually move stack variables into
fields of class (let's call it Mechanism), and there are some macros which
help to build method-state-machine, which can be resumed from internal
yield points.

In comparison with Resumable Functions proposal, such Stackless Coroutines
has following advantages/features:

1. Allocation of coroutine is completely orthogonal concept here - it is
easy to allocate object of such class Mechanism on stack, on heap, do
placement new and so on. It is completely transparent - there is no need
for "fuzzy" rules which allows optional elision of allocate/deallocate
calls.

2. Such class Mechanism has copy/move semantics, and it is possible to do
per-member/member-wise operations over fields (including "state index")
like operator==, serialize, and so on.
In contrast with Resumable Functions proposal this allows:

* Generators which are Forward Iterators, not just single pass Input
Iterators.
* Scope-based lifetime management - Mechanism object can be "move"ed around.
* It is possible to copy Mechanism object, which helps to implement "fork"
semantics (for example
https://github.com/boostorg/asio/blob/master/example/cpp03/http/server4/server.cpp#L57-L62
). It is also can be used for implementation of List monad, which in
essence clones continuation and calls it with different arguments.
* It is possible to serialize object Mechanism, which can be used for
migration of "lightweight threads" over network into another node.

C++ Resumable Functions can be based on this "class Mechanism" approach.
Though there can be some differences from Boost.Asio version, like support
of unconstructed fields (which fields are constructed depends on current
"state index"; and per-member operations like destructor, copy, move,
operator=, serialize should be based on "state index" value).

Best Regards,
Evgeny Panasyuk

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_491_1934728360.1433588840213
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello All!<br><br>Boost.Asio has macro-based emulation of =
Stackless Coroutines:<br>http://www.boost.org/doc/libs/1_58_0/doc/html/boos=
t_asio/overview/core/coroutine.html<br>http://blog.think-async.com/2010/03/=
potted-guide-to-stackless-coroutines.html<br><br>In short, user of such cor=
outines should manually move stack variables into fields of class (let's ca=
ll it Mechanism), and there are some macros which help to build method-stat=
e-machine, which can be resumed from internal yield points.<br><br>In compa=
rison with Resumable Functions proposal, such Stackless Coroutines has foll=
owing advantages/features:<br><br>1. Allocation of coroutine is completely =
orthogonal concept here - it is easy to allocate object of such class Mecha=
nism on stack, on heap, do placement new and so on. It is completely transp=
arent - there is no need for "fuzzy" rules which allows optional elision of=
 allocate/deallocate calls.<br><br>2. Such class Mechanism has copy/move se=
mantics, and it is possible to do per-member/member-wise operations over fi=
elds (including "state index") like operator=3D=3D, serialize, and so on.<b=
r>In contrast with Resumable Functions proposal this allows:<br><br>* Gener=
ators which are Forward Iterators, not just single pass Input Iterators.<br=
>* Scope-based lifetime management - Mechanism object can be "move"ed aroun=
d.<br>* It is possible to copy Mechanism object, which helps to implement "=
fork" semantics (for example https://github.com/boostorg/asio/blob/master/e=
xample/cpp03/http/server4/server.cpp#L57-L62 ). It is also can be used for =
implementation of List monad, which in essence clones continuation and call=
s it with different arguments.<br>* It is possible to serialize object Mech=
anism, which can be used for migration of "lightweight threads" over networ=
k into another node.<br><br>C++ Resumable Functions can be based on this "c=
lass Mechanism" approach. Though there can be some differences from Boost.A=
sio version, like support of unconstructed fields (which fields are constru=
cted depends on current "state index"; and per-member operations like destr=
uctor, copy, move, operator=3D, serialize should be based on "state index" =
value).<br><br>Best Regards,<br>Evgeny Panasyuk<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_491_1934728360.1433588840213--
------=_Part_490_1709592339.1433588840213--

.