Topic: Continuations for C++?
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Mon, 1 Feb 2016 17:26:48 -0500
Raw View
--Apple-Mail=_8F5BE364-48B8-48B1-A806-962D09CB4A03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
When we get support for coroutines in C++, will this functionality exp=
ose the continuation-passing mechanisms upon which it will be built? I thi=
nk that it might be useful for users to be able to build things on top of t=
hem. =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_8F5BE364-48B8-48B1-A806-962D09CB4A03
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">&n=
bsp; When we get support for coroutines in C++, will this func=
tionality expose the continuation-passing mechanisms upon which it will be =
built? I think that it might be useful for users to be able to build =
things on top of them. </div><br class=3D""><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div class=3D"">=E2=80=94=E2=80=89Bry=
ce Glover</div><div class=3D"">=E3=80=80=E2=80=89<a href=3D"mailto:RandomDS=
devel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div>
</div>
<br class=3D""></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_8F5BE364-48B8-48B1-A806-962D09CB4A03--
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Mon, 1 Feb 2016 17:31:35 -0500
Raw View
--Apple-Mail=_CF853CB7-2C33-4E03-B55E-DE520DA4C6E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On Feb 1, 2016, at 5:26 PM, Bryce Glover <randomdsdevel@gmail.com> wrote:
>=20
> When we get support for coroutines in C++, will this functionality e=
xpose the continuation-passing mechanisms upon which it will be built? I t=
hink that it might be useful for users to be able to build things on top of=
them. =20
>=20
> =E2=80=94=E2=80=89Bryce Glover
> =E3=80=80=E2=80=89RandomDSdevel@gmail.com <mailto:RandomDSdevel@gmail.com=
>
Wait a minute, that might have been a rather na=C3=AFve question: I just f=
ound a blog post that explores how to use continuation-passing style in C++=
14. =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_CF853CB7-2C33-4E03-B55E-DE520DA4C6E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D"">On Feb 1, 2016, at 5:26 PM, Bryce G=
lover <<a href=3D"mailto:randomdsdevel@gmail.com" class=3D"">randomdsdev=
el@gmail.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><d=
iv class=3D""><meta http-equiv=3D"Content-Type" content=3D"text/html charse=
t=3Dutf-8" class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mod=
e: space; -webkit-line-break: after-white-space;" class=3D""><div class=3D"=
"> When we get support for coroutines in C++, will this =
functionality expose the continuation-passing mechanisms upon which it will=
be built? I think that it might be useful for users to be able to bu=
ild things on top of them. </div><br class=3D""><div class=3D"">
<div style=3D"letter-spacing: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -web=
kit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><d=
iv style=3D"letter-spacing: normal; orphans: auto; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; widows: auto; word-=
spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webki=
t-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><div=
class=3D"">=E2=80=94=E2=80=89Bryce Glover</div><div class=3D"">=E3=80=80=
=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" class=3D"">RandomDSdeve=
l@gmail.com</a></div></div></div></div></div></div></blockquote></div><div =
class=3D""><br class=3D""></div><div class=3D"">Wait a minute, that might h=
ave been a rather na=C3=AFve question: I just found a blog post that =
explores how to use continuation-passing style in C++14. </div><br cl=
ass=3D""><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div class=3D"">=E2=80=94=E2=80=89Bry=
ce Glover</div><div class=3D"">=E3=80=80=E2=80=89<a href=3D"mailto:RandomDS=
devel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div>
</div>
<br class=3D""></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_CF853CB7-2C33-4E03-B55E-DE520DA4C6E5--
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Mon, 1 Feb 2016 17:33:48 -0500
Raw View
--Apple-Mail=_DB9CC27D-01EA-4962-89FD-38F1BAA867CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On Feb 1, 2016, at 5:31 PM, Bryce Glover <randomdsdevel@gmail.com> wrote:
>=20
>> On Feb 1, 2016, at 5:26 PM, Bryce Glover <randomdsdevel@gmail.com <mailt=
o:randomdsdevel@gmail.com>> wrote:
>>=20
>> When we get support for coroutines in C++, will this functionality =
expose the continuation-passing mechanisms upon which it will be built? I =
think that it might be useful for users to be able to build things on top o=
f them. =20
>>=20
>> =E2=80=94=E2=80=89Bryce Glover
>> =E3=80=80=E2=80=89RandomDSdevel@gmail.com <mailto:RandomDSdevel@gmail.co=
m>
>=20
> Wait a minute, that might have been a rather na=C3=AFve question: I just=
found a blog post that explores how to use continuation-passing style in C=
++14. =20
>=20
> =E2=80=94=E2=80=89Bryce Glover
> =E3=80=80=E2=80=89RandomDSdevel@gmail.com <mailto:RandomDSdevel@gmail.com=
>
Heh, forgot to add the link <https://functionalcpp.wordpress.com/2013/11/19=
/continuation-passing-style/> to the text =E2=80=98a blog post=E2=80=A6=E2=
=80=99 Whoops! =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_DB9CC27D-01EA-4962-89FD-38F1BAA867CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On Feb 1, 2016, at 5=
:31 PM, Bryce Glover <<a href=3D"mailto:randomdsdevel@gmail.com" class=
=3D"">randomdsdevel@gmail.com</a>> wrote:</div><br class=3D"Apple-interc=
hange-newline"><div class=3D""><meta http-equiv=3D"Content-Type" content=3D=
"text/html charset=3Dutf-8" class=3D""><div style=3D"word-wrap: break-word;=
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D=
""><div class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On =
Feb 1, 2016, at 5:26 PM, Bryce Glover <<a href=3D"mailto:randomdsdevel@g=
mail.com" class=3D"">randomdsdevel@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><div class=3D""><meta http-equiv=3D"Content-=
Type" content=3D"text/html charset=3Dutf-8" class=3D""><div style=3D"word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div class=3D""> When we get support =
for coroutines in C++, will this functionality expose the continuation-pass=
ing mechanisms upon which it will be built? I think that it might be =
useful for users to be able to build things on top of them. </div><br=
class=3D""><div class=3D"">
<div style=3D"letter-spacing: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -web=
kit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><d=
iv style=3D"letter-spacing: normal; orphans: auto; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; widows: auto; word-=
spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webki=
t-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><div=
class=3D"">=E2=80=94=E2=80=89Bryce Glover</div><div class=3D"">=E3=80=80=
=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" class=3D"">RandomDSdeve=
l@gmail.com</a></div></div></div></div></div></div></blockquote></div><div =
class=3D""><br class=3D""></div><div class=3D"">Wait a minute, that might h=
ave been a rather na=C3=AFve question: I just found a blog post that =
explores how to use continuation-passing style in C++14. </div><br cl=
ass=3D""><div class=3D"">
<div style=3D"letter-spacing: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -web=
kit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><d=
iv style=3D"letter-spacing: normal; orphans: auto; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; widows: auto; word-=
spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webki=
t-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><div=
class=3D"">=E2=80=94=E2=80=89Bryce Glover</div><div class=3D"">=E3=80=80=
=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" class=3D"">RandomDSdeve=
l@gmail.com</a></div></div></div></div></div></div></blockquote></div><br c=
lass=3D""><div class=3D"">Heh, forgot to add the <a href=3D"https://fu=
nctionalcpp.wordpress.com/2013/11/19/continuation-passing-style/" class=3D"=
">link</a> to the text =E2=80=98a blog post=E2=80=A6=E2=80=99 Wh=
oops! </div><div class=3D""><br class=3D"webkit-block-placeholder"></=
div><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div class=3D"">=E2=80=94=E2=80=89Bry=
ce Glover</div><div class=3D"">=E3=80=80=E2=80=89<a href=3D"mailto:RandomDS=
devel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div></=
div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_DB9CC27D-01EA-4962-89FD-38F1BAA867CD--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 1 Feb 2016 20:25:48 -0800 (PST)
Raw View
------=_Part_6892_570173821.1454387148267
Content-Type: multipart/alternative;
boundary="----=_Part_6893_1303412094.1454387148267"
------=_Part_6893_1303412094.1454387148267
Content-Type: text/plain; charset=UTF-8
On Monday, February 1, 2016 at 5:26:53 PM UTC-5, Bryce Glover wrote:
>
> When we get support for coroutines in C++, will this functionality
> expose the continuation-passing mechanisms upon which it will be built? I
> think that it might be useful for users to be able to build things on top
> of them.
>
If you're talking about P0057 <http://wg21.link/P0057>-style coroutines,
not really. The idea of that coroutine proposal is to allow the
continuation of *the rest of your function*. That is, instead of passing a
function which will be continued by some process, you write your code as if
it were normal, non-continuation code. The `co_await` operator will
transmit your current function's execution to whomever it is that will
"schedule" its continuation (depending on the value of the expression and a
*truly* dizzying array of customization points).
But it's not something you could just shove a random function at and tell
it to continue it. Well, given how ludicrously customizable it is, you
could probably make it work that way. But that's not what it's *for*.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6893_1303412094.1454387148267
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, February 1, 2016 at 5:26:53 PM UTC-5, Bryce Glo=
ver wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-w=
rap:break-word"><div>=C2=A0 =C2=A0 =C2=A0When we get support for coroutines=
in C++, will this functionality expose the continuation-passing mechanisms=
upon which it will be built? =C2=A0I think that it might be useful for use=
rs to be able to build things on top of them.<br></div></div></blockquote><=
div><br>If you're talking about <a href=3D"http://wg21.link/P0057">P005=
7</a>-style coroutines, not really. The idea of that coroutine proposal is =
to allow the continuation of <i>the rest of your function</i>. That is, ins=
tead of passing a function which will be continued by some process, you wri=
te your code as if it were normal, non-continuation code. The `co_await` op=
erator will transmit your current function's execution to whomever it i=
s that will "schedule" its continuation (depending on the value o=
f the expression and a <i>truly</i> dizzying array of customization points)=
..<br><br>But it's not something you could just shove a random function =
at and tell it to continue it. Well, given how ludicrously customizable it =
is, you could probably make it work that way. But that's not what it=
9;s <i>for</i>.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_6893_1303412094.1454387148267--
------=_Part_6892_570173821.1454387148267--
.
Author: Oliver Kowalke <oliver.kowalke@gmail.com>
Date: Tue, 2 Feb 2016 08:47:14 +0100
Raw View
--089e011602f8e098f5052ac4b6ae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
P099R0 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf=
)
- allows to build coroutines, fibers and shift/reset operators on top of it
2016-02-01 23:26 GMT+01:00 Bryce Glover <randomdsdevel@gmail.com>:
> When we get support for coroutines in C++, will this functionality
> expose the continuation-passing mechanisms upon which it will be built? =
I
> think that it might be useful for users to be able to build things on top
> of them.
>
> =E2=80=94 Bryce Glover
> RandomDSdevel@gmail.com
>
> --
>
> ---
> 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
> https://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--089e011602f8e098f5052ac4b6ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">P099R0 (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2015/p0099r0.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2015/p0099r0.pdf</a>) - allows to build coroutines, fibers and shift/=
reset operators on top of it<br></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">2016-02-01 23:26 GMT+01:00 Bryce Glover <span dir=3D"l=
tr"><<a href=3D"mailto:randomdsdevel@gmail.com" target=3D"_blank">random=
dsdevel@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div st=
yle=3D"word-wrap:break-word"><div>=C2=A0 =C2=A0 =C2=A0When we get support f=
or coroutines in C++, will this functionality expose the continuation-passi=
ng mechanisms upon which it will be built?=C2=A0 I think that it might be u=
seful for users to be able to build things on top of them. =C2=A0</div><spa=
n class=3D"HOEnZb"><font color=3D"#888888"><br><div>
<div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-=
indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wra=
p:break-word"><div style=3D"color:rgb(0,0,0);letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;word-wrap:break-word"><div>=E2=80=94=E2=80=89Bryce Glover</div><div>=
=E3=80=80=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" target=3D"_bla=
nk">RandomDSdevel@gmail.com</a></div></div></div>
</div>
<br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/" target=3D"_blank">https://groups.google.com/a/isocpp.org/g=
roup/std-proposals/</a>.<br>
</font></span></blockquote></div><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" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--089e011602f8e098f5052ac4b6ae--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 2 Feb 2016 07:30:49 -0800 (PST)
Raw View
------=_Part_1033_1124653572.1454427049536
Content-Type: multipart/alternative;
boundary="----=_Part_1034_1167746928.1454427049537"
------=_Part_1034_1167746928.1454427049537
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 2, 2016 at 2:47:36 AM UTC-5, Oliver Kowalke wrote:
>
> P099R0 (
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf) -
> allows to build coroutines, fibers and shift/reset operators on top of it
>
I like P0099 (a lot), but I don't think it's a very good system for
*continuation*-style APIs. The reason being the difficulty in doing the
continuation part.
In order to continue the execution of a function (ie: what P0057's
`co_await` does), you have to do all of the following operations:
1. Halt the current execution.
2. Transfer scheduling of the continuation to someone else.
3. Return control of the current thread to whomever it is that should get
it.
In many cases, this is trivial with P0099. The case of generators, for
example, works fine. But it works fine because the code that schedules the
resumption of the function is also the code you are returning to. So it is
impossible for the coroutine to be resumed before you've transferred
control elsewhere.
P0057 is designed for cases where 2 and 3 are *different*. Where you're
firing off some potentially-asynchronous process that will execute
independently of the code that will receive the value.
The issue that P0099 has with this is scenario is that, in order to make
the potentially-asynchronous code work, you *must* do the items in the
order I outlined them above. That is, you need to halt the current
context's execution, such that after step 1, it is legal to continue its
execution. You then need to transfer control to someone else who may
asychronously resume that context's execution. That's why #1 has to happen
*first*; if #2 fires off a thread, you can't be sure that the thread won't
resume your function before you've finished with #3.
In order to do that with P0099, you need a third execution context. One
that is not part of the call stack of the continuation itself. This means
that step 1 halts its own context and starts up the external one; this
means that the context is ready to be continued. And therefore, both steps
1 and 3 require a context switch. And while these are not an onerous
burden, they aren't exactly *free* either. So it's not impossible to
implement, but this style of programming has quite a bit of overhead. Also,
P0099 doesn't have any systems in place to help with this, so you'll have
to build this machinery yourself.
I hope you're good at async programming, because it's *really* easy to get
wrong.
By contrast, P0057 does things correctly by default. Of course it does;
P0057 is *all about* continuation-based programming. That's what it's for,
so it does it very well. P0099 is really designed for generalized stack
manipulation. So specialized use cases require specific fiddling and so
forth.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1034_1167746928.1454427049537
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 2, 2016 at 2:47:36 AM UTC-5, Oliver K=
owalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
P099R0 (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/=
p0099r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fs=
c22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\46sa\75D\46sntz\0751\46usg\=
75AFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true;" onclick=3D"this.hre=
f=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\46sa\75D\46sntz\0751\46=
usg\75AFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true;">http://www.open=
-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0099r0.pdf</a>) - allow=
s to build coroutines, fibers and shift/reset operators on top of it<br></d=
iv></blockquote><div>=C2=A0<br>I like P0099 (a lot), but I don't think =
it's a very good system for <i>continuation</i>-style APIs. The reason =
being the difficulty in doing the continuation part.<br><br>In order to con=
tinue the execution of a function (ie: what P0057's `co_await` does), y=
ou have to do all of the following operations:<br><br>1. Halt the current e=
xecution.<br>2. Transfer scheduling of the continuation to someone else.<br=
>3. Return control of the current thread to whomever it is that should get =
it.<br><br>In many cases, this is trivial with P0099. The case of generator=
s, for example, works fine. But it works fine because the code that schedul=
es the resumption of the function is also the code you are returning to. So=
it is impossible for the coroutine to be resumed before you've transfe=
rred control elsewhere.<br><br>P0057 is designed for cases where 2 and 3 ar=
e <i>different</i>. Where you're firing off some potentially-asynchrono=
us process that will execute independently of the code that will receive th=
e value.<br><br>The issue that P0099 has with this is scenario is that, in =
order to make the potentially-asynchronous code work, you <i>must</i> do th=
e items in the order I outlined them above. That is, you need to halt the c=
urrent context's execution, such that after step 1, it is legal to cont=
inue its execution. You then need to transfer control to someone else who m=
ay asychronously resume that context's execution. That's why #1 has=
to happen <i>first</i>; if #2 fires off a thread, you can't be sure th=
at the thread won't resume your function before you've finished wit=
h #3.<br><br>In order to do that with P0099, you need a third execution con=
text. One that is not part of the call stack of the continuation itself. Th=
is means that step 1 halts its own context and starts up the external one; =
this means that the context is ready to be continued. And therefore, both s=
teps 1 and 3 require a context switch. And while these are not an onerous b=
urden, they aren't exactly <i>free</i> either. So it's not impossib=
le to implement, but this style of programming has quite a bit of overhead.=
Also, P0099 doesn't have any systems in place to help with this, so yo=
u'll have to build this machinery yourself.<br><br>I hope you're go=
od at async programming, because it's <i>really</i> easy to get wrong.<=
br><br>By contrast, P0057 does things correctly by default. Of course it do=
es; P0057 is <i>all about</i> continuation-based programming. That's wh=
at it's for, so it does it very well. P0099 is really designed for gene=
ralized stack manipulation. So specialized use cases require specific fiddl=
ing and so forth.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1034_1167746928.1454427049537--
------=_Part_1033_1124653572.1454427049536--
.
Author: Oliver Kowalke <oliver.kowalke@gmail.com>
Date: Tue, 2 Feb 2016 16:58:21 +0100
Raw View
--001a113d40be4309f5052acb93ff
Content-Type: text/plain; charset=UTF-8
2016-02-02 16:30 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> On Tuesday, February 2, 2016 at 2:47:36 AM UTC-5, Oliver Kowalke wrote:
>>
>> P099R0 (
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf) -
>> allows to build coroutines, fibers and shift/reset operators on top of it
>>
>
> In order to continue the execution of a function (ie: what P0057's
> `co_await` does), you have to do all of the following operations:
>
> 1. Halt the current execution.
> 2. Transfer scheduling of the continuation to someone else.
> 3. Return control of the current thread to whomever it is that should get
> it.
>
P099R0 does not involve threads and or scheduler(s)
execution_context::operator() does suspend current context and resumes
context represented by the execution_context
> You then need to transfer control to someone else who may asychronously
> resume that context's execution.
>
no, that's a false assumption - there is no 'someone else' the execution
control is transferred from context ctx1 to context ctx2
> That's why #1 has to happen *first*; if #2 fires off a thread,
>
again, no threads are required
> In order to do that with P0099, you need a third execution context.
>
not correct
one benefit of P099R0 over P057 is, that it provides symmetric context
switch while P057 is only about asymmetric
symmetric: the next context is arbitrary
asymmetric: control must be transferred back to caller
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113d40be4309f5052acb93ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2016=
-02-02 16:30 GMT+01:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span>:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Tues=
day, February 2, 2016 at 2:47:36 AM UTC-5, Oliver Kowalke wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">P099R0 (<a href=3D"http://www=
..open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" rel=3D"nofollow"=
target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/=
p0099r0.pdf</a>) - allows to build coroutines, fibers and shift/reset opera=
tors on top of it<br></div></blockquote></span><div>=C2=A0<br>In order to c=
ontinue the execution of a function (ie: what P0057's `co_await` does),=
you have to do all of the following operations:<br><br>1. Halt the current=
execution.<br>2. Transfer scheduling of the continuation to someone else.<=
br>3. Return control of the current thread to whomever it is that should ge=
t it.<br></div></div></blockquote><div><br>P099R0 does not involve threads =
and or scheduler(s)<br></div><div>execution_context::operator() does suspen=
d current context and resumes context represented by the execution_context<=
br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div>You then need to transfer control to someone else who may asychronously=
resume that context's execution.</div></div></blockquote><div><br></di=
v><div>no, that's a false assumption - there is no 'someone else=
9; the execution control is transferred from context ctx1 to context ctx2<b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>That's why #1 has to happen <i>first</i>; if #2 fires off a thread, =
</div></div></blockquote><div><br></div><div>again, no threads are required=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>In order to do that with P0099, you need a third execution context.</d=
iv></div></blockquote><div><br></div><div>not correct<br></div></div><br></=
div><div class=3D"gmail_extra">one benefit of P099R0 over P057 is, that it =
provides symmetric context switch while P057 is only about asymmetric<br></=
div><div class=3D"gmail_extra">symmetric: the next context is arbitrary<br>=
</div><div class=3D"gmail_extra">asymmetric: control must be transferred ba=
ck to caller<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a113d40be4309f5052acb93ff--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 2 Feb 2016 12:18:05 -0800 (PST)
Raw View
------=_Part_8652_80337872.1454444285490
Content-Type: multipart/alternative;
boundary="----=_Part_8653_103949550.1454444285491"
------=_Part_8653_103949550.1454444285491
Content-Type: text/plain; charset=UTF-8
BTW, I hope to see an updated P0099 revision or something similar for
Jacksonville.
On Tuesday, February 2, 2016 at 10:58:42 AM UTC-5, Oliver Kowalke wrote:
>
> 2016-02-02 16:30 GMT+01:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> On Tuesday, February 2, 2016 at 2:47:36 AM UTC-5, Oliver Kowalke wrote:
>>>
>>> P099R0 (
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf) -
>>> allows to build coroutines, fibers and shift/reset operators on top of it
>>>
>>
>> In order to continue the execution of a function (ie: what P0057's
>> `co_await` does), you have to do all of the following operations:
>>
>> 1. Halt the current execution.
>> 2. Transfer scheduling of the continuation to someone else.
>> 3. Return control of the current thread to whomever it is that should get
>> it.
>>
>
> P099R0 does not involve threads and or scheduler(s)
> execution_context::operator() does suspend current context and resumes
> context represented by the execution_context
>
>
>
>> You then need to transfer control to someone else who may asychronously
>> resume that context's execution.
>>
>
> no, that's a false assumption - there is no 'someone else' the execution
> control is transferred from context ctx1 to context ctx2
>
Well, I didn't think this was going to get so pedantic, or I would have
used terminology more carefully. That's my fault; *every* discussion of
coroutines ends in pedantry.
So allow me to restate this more formally, using P0099's terminology:
1. The current execution_context must cease executing.
2. The previously executing context `ctx1` now needs to be handed off to
whomever will continue it.
3. Some other execution_context `ctx2` now needs to be resumed, presumably
with some information about how to ask if `ctx1` has finished or has new
data or whatever.
And these things must happen in this order.
The problem I pointed out is this: what execution context is running after
step 1, which executes the code needed for step 2?
See, the problem is this. I want to stop executing and give my context to
someone else who will then resume my execution. How do I do that? Under
naive use of P0099, you'd do this:
SomeoneElse(execution_context::current()); //Gives my context to someone
else.
//Setup promise/future/whatever interface to `ctx2`.
ctx2(); //Start up a different context.
This can work... so long as `SomeoneElse` does not attempt to *immediately*
resume the context I give it. And by "immediately", I mean "before I call
`ctx2()`".
Now, you might say that this is incredibly silly. Nobody would write
`SomeoneElse` in a way that would instantly resume the execution_context it
was given.
Well the fact is... they can. Because they may not have a choice in the
matter. If `SomeoneElse` is an asynchronous function call (AKA, *everything*
in the Networking TS), then we have a scheduling problem. Furthermore, it
is not a scheduling problem that can easily be sorted out, since there is
no way to say, "wait until this execution_context has finished executing."
That's a problem, and it is not one that can easily be solved. The only way
I can see how to solve it is like this:
//Setup promise/future/etc interface to `ctx2`.
execution_context temp{[=](execution_context old)
{
SomeoneElse(old);
ctx2(); //Invoke ctx2.
}, execution_context::current()};
temp();
You have to create a *whole execution context*, just to do a simple switch.
I'm sure you can get rid of the local creation of this context. You could
have some thread_local context that you create with a minimal stack, who's
purpose is to do this kind of switching. But the fact is, you're still
having to do two context switches: once to the intermediary context, and
one to the final destination.
You *cannot* do with just the initial and final contexts; you need that
third context in there that acts as an intermediary.
P0057 gets around this with *explicit* compiler magic. When `co_await`
happens, the place where the coroutine is suspended and where it is resumed
are explicitly different places. The resume point is well after the suspend
point, and between them is where the equivalent of `SomeoneElse(old)`
happens, followed by returning control to `ctx2` (ie: the caller).
Therefore, if `SomeoneElse` does indeed immediately resume the coroutine in
a different thread, that's fine; control jumps to the resume point, which
is past the `SomeoneElse(old)` part.
P0099 requires a lot of grunt work to get the equivalent functionality.
Maybe you could encapsulate it into some kind of library, but thus far, I
have yet to see anyone actually try it. And even if you do, it *still* will
require two context switches.
>
>> That's why #1 has to happen *first*; if #2 fires off a thread,
>>
>
> again, no threads are required
>
Note the word "If". I never said that threads were required. P0057 doesn't
require threads either. Indeed several examples of `co_await` check a
mutex, and only create a thread if the mutex isn't locked. Otherwise, they
continue the function right then.
Behavior that P0099 emulating would still require the above code. Indeed,
immediate resumption in this thread would require far more code, since you
have to keep the intermediate context alive once `SomeoneElse` explicitly
back to `old`. Indeed, you also need to find a way to get the
promise/whatever data to `ctx2`, since that hasn't happened yet.
In short, it's a big mess. Again, maybe some library can sort out the
details into something workable, but I have yet to see it.
> In order to do that with P0099, you need a third execution context.
>>
>
> not correct
>
one benefit of P099R0 over P057 is, that it provides symmetric context
> switch while P057 is only about asymmetric
> symmetric: the next context is arbitrary
> asymmetric: control must be transferred back to caller
Yes, but you're just proving my point. Symmetric coroutines are not
*continuations*.
The whole point of P0057 continuations are that you can write continuations
that don't *look like* continuations. Normally, continuations have to
involve lambdas, where you do this:
void func()
{
//First part of funciton
auto test = PossiblyAsyncTask([=](auto val) {/*Rest of my function*/});
while(!test.IsFinished())
//Do some stuff.
}
This makes it hard to follow the code's logic. And it becomes increasingly
burdensome for complex cases. P0057 makes these cases trivial:
auto func2()
{
//First part of function.
auto val = co_await PossiblyAsyncTask(...);
//Rest of the function
co_return ...;
}
void func1()
{
auto test = func2();
while(!test.IsFinished())
//Do some stuff.
}
P0099 is very good functionality. As far as I'm concerned, it's far more
*generally* useful than P0057. But P0099 is just a poor fit for cases like
this; it's just a big pain. P0057 makes hard asynchronous continuations
like this trivially easy. No spurious lambdas. No extra execution context.
No baggy syntax for doing something so simple.
P0099 is about something else: coroutines, execution stacks, and the like.
They're solving two sets of problems that are only tangentially related.
And while you *could* use either one to solve the problems of the other,
solving problems outside of their domain is increasingly hard. Using P0057
for fiber-like coroutines is... stupidly difficult. While using P0099 for
potentially asynchronous continuations is working against its strengths.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_8653_103949550.1454444285491
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">BTW, I hope to see an updated P0099 revision or something =
similar for Jacksonville.<br><br>On Tuesday, February 2, 2016 at 10:58:42 A=
M UTC-5, Oliver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote">2016-02-02 16:30 GMT+01:00=
Nicol Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"rmX0vT79GwAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">jmck...@gmail.com</a>></span>:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><span>On Tuesday, February 2, 2016 =
at 2:47:36 AM UTC-5, Oliver Kowalke wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">P099R0 (<a href=3D"http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2015/p0099r0.pdf" rel=3D"nofollow" target=3D"_blank" onm=
ousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww=
..open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\46s=
a\75D\46sntz\0751\46usg\75AFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return tr=
ue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2=
Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf=
\46sa\75D\46sntz\0751\46usg\75AFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';retur=
n true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>=
p0099r0.pdf</a>) - allows to build coroutines, fibers and shift/reset opera=
tors on top of it<br></div></blockquote></span><div>=C2=A0<br>In order to c=
ontinue the execution of a function (ie: what P0057's `co_await` does),=
you have to do all of the following operations:<br><br>1. Halt the current=
execution.<br>2. Transfer scheduling of the continuation to someone else.<=
br>3. Return control of the current thread to whomever it is that should ge=
t it.<br></div></div></blockquote><div><br>P099R0 does not involve threads =
and or scheduler(s)<br></div><div>execution_context::operator() does suspen=
d current context and resumes context represented by the execution_context<=
br></div></div></div></div></blockquote><blockquote style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"=
class=3D"gmail_quote"><div><br></div></blockquote><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>You then need to transfer control to someone else who may asychronously re=
sume that context's execution.</div></div></blockquote><div><br></div><=
div>no, that's a false assumption - there is no 'someone else' =
the execution control is transferred from context ctx1 to context ctx2<br><=
/div></div></div></div></blockquote><div><br>Well, I didn't think this =
was going to get so pedantic, or I would have used terminology more careful=
ly. That's my fault; <i>every</i> discussion of coroutines ends in peda=
ntry.<br><br>So allow me to restate this more formally, using P0099's t=
erminology:<br><br>1. The current execution_context must cease executing.<b=
r>2. The previously executing context `ctx1` now needs to be handed off to =
whomever will continue it.<br>3. Some other execution_context `ctx2` now ne=
eds to be resumed, presumably with some information about how to ask if `ct=
x1` has finished or has new data or whatever.<br><br>And these things must =
happen in this order.<br><br>The problem I pointed out is this: what execut=
ion context is running after step 1, which executes the code needed for ste=
p 2?<br><br>See, the problem is this. I want to stop executing and give my =
context to someone else who will then resume my execution. How do I do that=
? Under naive use of P0099, you'd do this:<br><br><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">SomeoneElse</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">execution_context</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">current</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">());</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">//Gives my context to someone else.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">//Setup promise/future/whatever interface=
to `ctx2`.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>ctx2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0<=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">//Start up =
a different context.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div><br>This can work... so long as `So=
meoneElse` does not attempt to <i>immediately</i> resume the context I give=
it. And by "immediately", I mean "before I call `ctx2()`&qu=
ot;.<br><br>Now, you might say that this is incredibly silly. Nobody would =
write `SomeoneElse` in a way that would instantly resume the execution_cont=
ext it was given.<br><br>Well the fact is... they can. Because they may not=
have a choice in the matter. If `SomeoneElse` is an asynchronous function =
call (AKA, <i>everything</i> in the Networking TS), then we have a scheduli=
ng problem. Furthermore, it is not a scheduling problem that can easily be =
sorted out, since there is no way to say, "wait until this execution_c=
ontext has finished executing."<br><br>That's a problem, and it is=
not one that can easily be solved. The only way I can see how to solve it =
is like this:<br><br><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div=
class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">//Setup promise/future/etc interface to `ctx2`.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br>execution_context te=
mp</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{[=3D](<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">execution_c=
ontext old</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">SomeoneElse</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">old</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 ctx2</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">//Invoke ctx2.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">},</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> execution_context</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">current</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">()};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br>temp</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">();</span></div></code></div><br>You have to create a <i>whole execution=
context</i>, just to do a simple switch. I'm sure you can get rid of t=
he local creation of this context. You could have some thread_local context=
that you create with a minimal stack, who's purpose is to do this kind=
of switching. But the fact is, you're still having to do two context s=
witches: once to the intermediary context, and one to the final destination=
..<br><br>You <i>cannot</i> do with just the initial and final contexts; you=
need that third context in there that acts as an intermediary.<br><br>P005=
7 gets around this with <i>explicit</i> compiler magic. When `co_await` hap=
pens, the place where the coroutine is suspended and where it is resumed ar=
e explicitly different places. The resume point is well after the suspend p=
oint, and between them is where the equivalent of `SomeoneElse(old)` happen=
s, followed by returning control to `ctx2` (ie: the caller). Therefore, if =
`SomeoneElse` does indeed immediately resume the coroutine in a different t=
hread, that's fine; control jumps to the resume point, which is past th=
e `SomeoneElse(old)` part.<br><br>P0099 requires a lot of grunt work to get=
the equivalent functionality. Maybe you could encapsulate it into some kin=
d of library, but thus far, I have yet to see anyone actually try it. And e=
ven if you do, it <i>still</i> will require two context switches.<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div=
class=3D"gmail_quote"><div></div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div>That's why #1 has to happen <i>first</i>; =
if #2 fires off a thread, </div></div></blockquote><div><br></div><div>agai=
n, no threads are required<br></div></div></div></div></blockquote><div><br=
>Note the word "If". I never said that threads were required. P00=
57 doesn't require threads either. Indeed several examples of `co_await=
` check a mutex, and only create a thread if the mutex isn't locked. Ot=
herwise, they continue the function right then.<br><br>Behavior that P0099 =
emulating would still require the above code. Indeed, immediate resumption =
in this thread would require far more code, since you have to keep the inte=
rmediate context alive once `SomeoneElse` explicitly back to `old`. Indeed,=
you also need to find a way to get the promise/whatever data to `ctx2`, si=
nce that hasn't happened yet.<br><br>In short, it's a big mess. Aga=
in, maybe some library can sort out the details into something workable, bu=
t I have yet to see it.<br>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>In order to do th=
at with P0099, you need a third execution context.</div></div></blockquote>=
<div><br></div><div>not correct<br></div></div></div></div></blockquote><di=
v><br></div><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><=
div>one benefit of P099R0 over P057 is, that it provides symmetric context =
switch while P057 is only about asymmetric<br></div><div>symmetric: the nex=
t context is arbitrary<br></div>asymmetric: control must be transferred bac=
k to caller</blockquote><div><br>Yes, but you're just proving my point.=
Symmetric coroutines are not <i>continuations</i>.<br><br>The whole point =
of P0057 continuations are that you can write continuations that don't =
<i>look like</i> continuations. Normally, continuations have to involve lam=
bdas, where you do this:<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> func</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </s=
pan><span style=3D"color: #800;" class=3D"styled-by-prettify">//First part =
of funciton</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tes=
t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">PossiblyAsyncTask</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">([=3D](</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> val</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #800;" class=3D"styl=
ed-by-prettify">/*Rest of my function*/</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">});</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br>=C2=A0 </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">while</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(!</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">test</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">.</span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>IsFinished</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>())</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">//Do some stuff.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span></div></code></div><br>This makes it hard to follow the code=
9;s logic. And it becomes increasingly burdensome for complex cases. P0057 =
makes these cases trivial:<br><br><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> func2</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//Firs=
t part of function.</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> val </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> co_awa=
it </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Possibl=
yAsyncTask</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(...);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//R=
est of the function</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>=C2=A0 co_return </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">...;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">voi=
d</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> func1</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> test </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> func2</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>=C2=A0 <br>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">while</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(!</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">test</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #606;" class=3D"styled-by-prettify">IsF=
inished</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//=
Do some stuff.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span></div></code></div><br>P0099 is very good functionality. As far as I&=
#39;m concerned, it's far more <i>generally</i> useful than P0057. But =
P0099 is just a poor fit for cases like this; it's just a big pain. P00=
57 makes hard asynchronous continuations like this trivially easy. No spuri=
ous lambdas. No extra execution context. No baggy syntax for doing somethin=
g so simple.<br><br>P0099 is about something else: coroutines, execution st=
acks, and the like. They're solving two sets of problems that are only =
tangentially related. And while you <i>could</i> use either one to solve th=
e problems of the other, solving problems outside of their domain is increa=
singly hard. Using P0057 for fiber-like coroutines is... stupidly difficult=
.. While using P0099 for potentially asynchronous continuations is working a=
gainst its strengths.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_8653_103949550.1454444285491--
------=_Part_8652_80337872.1454444285490--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Tue, 2 Feb 2016 16:31:57 -0800 (PST)
Raw View
------=_Part_8827_1945977298.1454459517304
Content-Type: multipart/alternative;
boundary="----=_Part_8828_2070755856.1454459517304"
------=_Part_8828_2070755856.1454459517304
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 2, 2016 at 8:18:06 PM UTC, Nicol Bolas wrote:
>
> BTW, I hope to see an updated P0099 revision or something similar for
> Jacksonville.
>
> On Tuesday, February 2, 2016 at 10:58:42 AM UTC-5, Oliver Kowalke wrote:
>>
>> 2016-02-02 16:30 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
>>
>>> On Tuesday, February 2, 2016 at 2:47:36 AM UTC-5, Oliver Kowalke wrote:
>>>>
>>>> P099R0 (
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf) -
>>>> allows to build coroutines, fibers and shift/reset operators on top of it
>>>>
>>>
>>> In order to continue the execution of a function (ie: what P0057's
>>> `co_await` does), you have to do all of the following operations:
>>>
>>> 1. Halt the current execution.
>>> 2. Transfer scheduling of the continuation to someone else.
>>> 3. Return control of the current thread to whomever it is that should
>>> get it.
>>>
>>
>> P099R0 does not involve threads and or scheduler(s)
>> execution_context::operator() does suspend current context and resumes
>> context represented by the execution_context
>>
>
>>
>>
>>> You then need to transfer control to someone else who may asychronously
>>> resume that context's execution.
>>>
>>
>> no, that's a false assumption - there is no 'someone else' the execution
>> control is transferred from context ctx1 to context ctx2
>>
>
> Well, I didn't think this was going to get so pedantic, or I would have
> used terminology more carefully. That's my fault; *every* discussion of
> coroutines ends in pedantry.
>
amen!
>
> So allow me to restate this more formally, using P0099's terminology:
>
> 1. The current execution_context must cease executing.
> 2. The previously executing context `ctx1` now needs to be handed off to
> whomever will continue it.
> 3. Some other execution_context `ctx2` now needs to be resumed, presumably
> with some information about how to ask if `ctx1` has finished or has new
> data or whatever.
>
> And these things must happen in this order.
>
> The problem I pointed out is this: what execution context is running after
> step 1, which executes the code needed for step 2?
>
> See, the problem is this. I want to stop executing and give my context to
> someone else who will then resume my execution. How do I do that? Under
> naive use of P0099, you'd do this:
>
> SomeoneElse(execution_context::current()); //Gives my context to someone
> else.
> //Setup promise/future/whatever interface to `ctx2`.
> ctx2(); //Start up a different context.
>
> This can work... so long as `SomeoneElse` does not attempt to
> *immediately* resume the context I give it. And by "immediately", I mean
> "before I call `ctx2()`".
>
> Now, you might say that this is incredibly silly. Nobody would write
> `SomeoneElse` in a way that would instantly resume the execution_context it
> was given.
>
> Well the fact is... they can. Because they may not have a choice in the
> matter. If `SomeoneElse` is an asynchronous function call (AKA,
> *everything* in the Networking TS), then we have a scheduling problem.
> Furthermore, it is not a scheduling problem that can easily be sorted out,
> since there is no way to say, "wait until this execution_context has
> finished executing."
>
> That's a problem, and it is not one that can easily be solved. The only
> way I can see how to solve it is like this:
>
> //Setup promise/future/etc interface to `ctx2`.
>
> execution_context temp{[=](execution_context old)
> {
> SomeoneElse(old);
> ctx2(); //Invoke ctx2.
> }, execution_context::current()};
>
> temp();
>
> You have to create a *whole execution context*, just to do a simple
> switch. I'm sure you can get rid of the local creation of this context. You
> could have some thread_local context that you create with a minimal stack,
> who's purpose is to do this kind of switching. But the fact is, you're
> still having to do two context switches: once to the intermediary context,
> and one to the final destination.
>
> You *cannot* do with just the initial and final contexts; you need that
> third context in there that acts as an intermediary.
>
FWIW, me and Oliver discussed this extensively a few months ago. As a
recap, what I proposed is something like this:
yield_with(ctx2, [](auto ctx) { SomeoneElse(move(ctx)); return ctx; });
Only one context switch is needed. Yield_with can be implemented on top of
P0099, but builtin support would be better.
> P0057 gets around this with *explicit* compiler magic. When `co_await`
> happens, the place where the coroutine is suspended and where it is resumed
> are explicitly different places. The resume point is well after the suspend
> point, and between them is where the equivalent of `SomeoneElse(old)`
> happens, followed by returning control to `ctx2` (ie: the caller).
> Therefore, if `SomeoneElse` does indeed immediately resume the coroutine in
> a different thread, that's fine; control jumps to the resume point, which
> is past the `SomeoneElse(old)` part.
>
> P0099 requires a lot of grunt work to get the equivalent functionality.
> Maybe you could encapsulate it into some kind of library, but thus far, I
> have yet to see anyone actually try it. And even if you do, it *still*
> will require two context switches.
>
>
>>
>>> That's why #1 has to happen *first*; if #2 fires off a thread,
>>>
>>
>> again, no threads are required
>>
>
> Note the word "If". I never said that threads were required. P0057 doesn't
> require threads either. Indeed several examples of `co_await` check a
> mutex, and only create a thread if the mutex isn't locked. Otherwise, they
> continue the function right then.
>
> Behavior that P0099 emulating would still require the above code. Indeed,
> immediate resumption in this thread would require far more code, since you
> have to keep the intermediate context alive once `SomeoneElse` explicitly
> back to `old`. Indeed, you also need to find a way to get the
> promise/whatever data to `ctx2`, since that hasn't happened yet.
>
> In short, it's a big mess. Again, maybe some library can sort out the
> details into something workable, but I have yet to see it.
>
>
>> In order to do that with P0099, you need a third execution context.
>>>
>>
>> not correct
>>
>
>
> one benefit of P099R0 over P057 is, that it provides symmetric context
>> switch while P057 is only about asymmetric
>> symmetric: the next context is arbitrary
>> asymmetric: control must be transferred back to caller
>
>
> Yes, but you're just proving my point. Symmetric coroutines are not
> *continuations*.
>
>
They are actually.
> The whole point of P0057 continuations are that you can write
> continuations that don't *look like* continuations. Normally,
> continuations have to involve lambdas, where you do this:
>
> void func()
> {
> //First part of funciton
> auto test = PossiblyAsyncTask([=](auto val) {/*Rest of my function*/});
>
> while(!test.IsFinished())
> //Do some stuff.
> }
>
>
That's not really a proper first-class continuation. That's simulating a
continuation by manual-rewriting with a lambda. It is like simulating a for
loop with goto and if statements. Stackful coroutines (both symmetric and
asymmetric) are in fact equivalent to first class one shot delimited
continuation.
-- gpd
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_8828_2070755856.1454459517304
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 2, 2016 at 8:18:06 PM UTC, Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">BTW, =
I hope to see an updated P0099 revision or something similar for Jacksonvil=
le.<br><br>On Tuesday, February 2, 2016 at 10:58:42 AM UTC-5, Oliver Kowalk=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote">2016-02-02 16:30 GMT+01:00 Nicol Bolas <span dir=3D"l=
tr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span>:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><span>On Tuesday, February 2, 2016 at=
2:47:36 AM UTC-5, Oliver Kowalke wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">P099R0 (<a href=3D"http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2015/p0099r0.pdf" rel=3D"nofollow" target=3D"_blank" onmou=
sedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.o=
pen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\46sa\=
75D\46sntz\0751\46usg\75AFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fw=
ww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return =
true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0=
099r0.pdf</a>) - allows to build coroutines, fibers and shift/reset operato=
rs on top of it<br></div></blockquote></span><div>=C2=A0<br>In order to con=
tinue the execution of a function (ie: what P0057's `co_await` does), y=
ou have to do all of the following operations:<br><br>1. Halt the current e=
xecution.<br>2. Transfer scheduling of the continuation to someone else.<br=
>3. Return control of the current thread to whomever it is that should get =
it.<br></div></div></blockquote><div><br>P099R0 does not involve threads an=
d or scheduler(s)<br></div><div>execution_context::operator() does suspend =
current context and resumes context represented by the execution_context<br=
></div></div></div></div></blockquote><blockquote style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"=
gmail_quote"><div><br></div></blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>You then need=
to transfer control to someone else who may asychronously resume that cont=
ext's execution.</div></div></blockquote><div><br></div><div>no, that&#=
39;s a false assumption - there is no 'someone else' the execution =
control is transferred from context ctx1 to context ctx2<br></div></div></d=
iv></div></blockquote><div><br>Well, I didn't think this was going to g=
et so pedantic, or I would have used terminology more carefully. That's=
my fault; <i>every</i> discussion of coroutines ends in pedantry.<br></div=
></div></blockquote><div><br>amen!<br>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><br>So allow me to restate this m=
ore formally, using P0099's terminology:<br><br>1. The current executio=
n_context must cease executing.<br>2. The previously executing context `ctx=
1` now needs to be handed off to whomever will continue it.<br>3. Some othe=
r execution_context `ctx2` now needs to be resumed, presumably with some in=
formation about how to ask if `ctx1` has finished or has new data or whatev=
er.<br><br>And these things must happen in this order.<br><br>The problem I=
pointed out is this: what execution context is running after step 1, which=
executes the code needed for step 2?<br><br>See, the problem is this. I wa=
nt to stop executing and give my context to someone else who will then resu=
me my execution. How do I do that? Under naive use of P0099, you'd do t=
his:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><c=
ode><div><span style=3D"color:#606">SomeoneElse</span><span style=3D"color:=
#660">(</span><span style=3D"color:#000">execution_context</span><span styl=
e=3D"color:#660">:<wbr>:</span><span style=3D"color:#000">current</span><sp=
an style=3D"color:#660">());</span><span style=3D"color:#000"> </span><span=
style=3D"color:#800">//Gives my context to someone else.</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#800">//Setup promise/futur=
e/whatever interface to `ctx2`.</span><span style=3D"color:#000"><br>ctx2</=
span><span style=3D"color:#660">();</span><span style=3D"color:#000"> =C2=
=A0</span><span style=3D"color:#800">//Start up a different context.</span>=
<span style=3D"color:#000"><br></span></div></code></div><br>This can work.=
... so long as `SomeoneElse` does not attempt to <i>immediately</i> resume t=
he context I give it. And by "immediately", I mean "before I=
call `ctx2()`".<br><br>Now, you might say that this is incredibly sil=
ly. Nobody would write `SomeoneElse` in a way that would instantly resume t=
he execution_context it was given.<br><br>Well the fact is... they can. Bec=
ause they may not have a choice in the matter. If `SomeoneElse` is an async=
hronous function call (AKA, <i>everything</i> in the Networking TS), then w=
e have a scheduling problem. Furthermore, it is not a scheduling problem th=
at can easily be sorted out, since there is no way to say, "wait until=
this execution_context has finished executing."<br><br>That's a p=
roblem, and it is not one that can easily be solved. The only way I can see=
how to solve it is like this:<br><br><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x;word-wrap:break-word"><code><div><span style=3D"color:#800">//Setup promi=
se/future/etc interface to `ctx2`.</span><span style=3D"color:#000"><br><br=
>execution_context temp</span><span style=3D"color:#660">{[=3D](</span><spa=
n style=3D"color:#000">execution_context old</span><span style=3D"color:#66=
0">)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:=
#606">SomeoneElse</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">old</span><span style=3D"color:#660">);</span><span style=3D"col=
or:#000"><br>=C2=A0 ctx2</span><span style=3D"color:#660">();</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#800">//Invoke ctx2.</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#660">},</span>=
<span style=3D"color:#000"> execution_context</span><span style=3D"color:#6=
60">::</span><span style=3D"color:#000">current</span><span style=3D"color:=
#660">()};</span><span style=3D"color:#000"><br><br>temp</span><span style=
=3D"color:#660">();</span></div></code></div><br>You have to create a <i>wh=
ole execution context</i>, just to do a simple switch. I'm sure you can=
get rid of the local creation of this context. You could have some thread_=
local context that you create with a minimal stack, who's purpose is to=
do this kind of switching. But the fact is, you're still having to do =
two context switches: once to the intermediary context, and one to the fina=
l destination.<br><br>You <i>cannot</i> do with just the initial and final =
contexts; you need that third context in there that acts as an intermediary=
..<br></div></div></blockquote><div><br>FWIW, me and Oliver discussed this e=
xtensively a few months ago. As a recap, what=C2=A0 I proposed is something=
like this:<br>=C2=A0<br>=C2=A0 yield_with(ctx2, [](auto ctx) { SomeoneElse=
(move(ctx)); return ctx; });<br><br>Only one context switch is needed. Yiel=
d_with can be implemented on top of P0099, but builtin support would be bet=
ter.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><br>P0057 gets around this with <i>explicit</i> compiler magic. W=
hen `co_await` happens, the place where the coroutine is suspended and wher=
e it is resumed are explicitly different places. The resume point is well a=
fter the suspend point, and between them is where the equivalent of `Someon=
eElse(old)` happens, followed by returning control to `ctx2` (ie: the calle=
r). Therefore, if `SomeoneElse` does indeed immediately resume the coroutin=
e in a different thread, that's fine; control jumps to the resume point=
, which is past the `SomeoneElse(old)` part.<br><br>P0099 requires a lot of=
grunt work to get the equivalent functionality. Maybe you could encapsulat=
e it into some kind of library, but thus far, I have yet to see anyone actu=
ally try it. And even if you do, it <i>still</i> will require two context s=
witches.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div></div><div>=C2=A0</div><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>That's why #1 has to happen <=
i>first</i>; if #2 fires off a thread, </div></div></blockquote><div><br></=
div><div>again, no threads are required<br></div></div></div></div></blockq=
uote><div><br>Note the word "If". I never said that threads were =
required. P0057 doesn't require threads either. Indeed several examples=
of `co_await` check a mutex, and only create a thread if the mutex isn'=
;t locked. Otherwise, they continue the function right then.<br><br>Behavio=
r that P0099 emulating would still require the above code. Indeed, immediat=
e resumption in this thread would require far more code, since you have to =
keep the intermediate context alive once `SomeoneElse` explicitly back to `=
old`. Indeed, you also need to find a way to get the promise/whatever data =
to `ctx2`, since that hasn't happened yet.<br><br>In short, it's a =
big mess. Again, maybe some library can sort out the details into something=
workable, but I have yet to see it.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></di=
v><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>In order =
to do that with P0099, you need a third execution context.</div></div></blo=
ckquote><div><br></div><div>not correct<br></div></div></div></div></blockq=
uote><div><br></div><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><=
div>one benefit of P099R0 over P057 is, that it provides symmetric context =
switch while P057 is only about asymmetric<br></div><div>symmetric: the nex=
t context is arbitrary<br></div>asymmetric: control must be transferred bac=
k to caller</blockquote><div><br>Yes, but you're just proving my point.=
Symmetric coroutines are not <i>continuations</i>.<br><br></div></div></bl=
ockquote><div><br>They are actually.<br>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>The whole point of P0057 contin=
uations are that you can write continuations that don't <i>look like</i=
> continuations. Normally, continuations have to involve lambdas, where you=
do this:<br><br><div style=3D"background-color:rgb(250,250,250);border-col=
or:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wor=
d"><code><div><span style=3D"color:#008">void</span><span style=3D"color:#0=
00"> func</span><span style=3D"color:#660">()</span><span style=3D"color:#0=
00"><br></span><span style=3D"color:#660">{</span><span style=3D"color:#000=
"><br>=C2=A0 </span><span style=3D"color:#800">//First part of funciton</sp=
an><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">=
auto</span><span style=3D"color:#000"> test </span><span style=3D"color:#66=
0">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#606">=
PossiblyAsyncTask</span><span style=3D"color:#660">([=3D](</span><span styl=
e=3D"color:#008">auto</span><span style=3D"color:#000"> val</span><span sty=
le=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">{</span><span style=3D"color:#800">/*Rest of my function*/</sp=
an><span style=3D"color:#660">});</span><span style=3D"color:#000"><br><br>=
=C2=A0 </span><span style=3D"color:#008">while</span><span style=3D"color:#=
660">(!</span><span style=3D"color:#000">test</span><span style=3D"color:#6=
60">.</span><span style=3D"color:#606">IsFinished</span><span style=3D"colo=
r:#660">())</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span=
style=3D"color:#800">//Do some stuff.</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#660">}</span></div></code></div><br></div></d=
iv></blockquote><div><br>That's not really a proper first-class continu=
ation. That's simulating a continuation by manual-rewriting with a lamb=
da. It is like simulating a for loop with goto and if statements. Stackful =
coroutines (both symmetric and asymmetric) are in fact equivalent to first =
class one shot delimited continuation. <br><br>-- gpd<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_8828_2070755856.1454459517304--
------=_Part_8827_1945977298.1454459517304--
.
Author: Oliver Kowalke <oliver.kowalke@gmail.com>
Date: Wed, 3 Feb 2016 08:55:29 +0100
Raw View
--001a11c1bd4239c309052ad8f20f
Content-Type: text/plain; charset=UTF-8
2016-02-02 21:18 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> BTW, I hope to see an updated P0099 revision or something similar for
> Jacksonville.
>
maybe
<snip>
see Giovanni's comment
But because the OP asked "...useful for users to be able to build things on
top of them..." - I believe that the mechanisms described in P099 are
suitable to build high-level abstractions (as demonstrated in some boost
libraries).
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c1bd4239c309052ad8f20f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2016-02-02 21:18 GMT+01:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"mai=
lto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></spa=
n>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">B=
TW, I hope to see an updated P0099 revision or something similar for Jackso=
nville.<br></div></blockquote><div><br></div><div>maybe<br><br></div><div d=
ir=3D"ltr"><snip><br></div></div>see Giovanni's comment<br><br></=
div><div class=3D"gmail_extra">But because the OP asked "...useful for=
users to be able to build things on top of them..." - I believe that =
the mechanisms described in P099 are suitable to build high-level abstracti=
ons (as demonstrated in some boost libraries).<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--001a11c1bd4239c309052ad8f20f--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 3 Feb 2016 10:56:33 -0800 (PST)
Raw View
------=_Part_1390_109409642.1454525793951
Content-Type: multipart/alternative;
boundary="----=_Part_1391_1077262577.1454525793953"
------=_Part_1391_1077262577.1454525793953
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 2, 2016 at 7:31:57 PM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Tuesday, February 2, 2016 at 8:18:06 PM UTC, Nicol Bolas wrote:
>>
>> BTW, I hope to see an updated P0099 revision or something similar for
>> Jacksonville.
>>
>> On Tuesday, February 2, 2016 at 10:58:42 AM UTC-5, Oliver Kowalke wrote:
>>>
>>> 2016-02-02 16:30 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
>>>
>>>> On Tuesday, February 2, 2016 at 2:47:36 AM UTC-5, Oliver Kowalke wrote:
>>>>>
>>>>> P099R0 (
>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf)
>>>>> - allows to build coroutines, fibers and shift/reset operators on top of it
>>>>>
>>>>
>>>> In order to continue the execution of a function (ie: what P0057's
>>>> `co_await` does), you have to do all of the following operations:
>>>>
>>>> 1. Halt the current execution.
>>>> 2. Transfer scheduling of the continuation to someone else.
>>>> 3. Return control of the current thread to whomever it is that should
>>>> get it.
>>>>
>>>
>>> P099R0 does not involve threads and or scheduler(s)
>>> execution_context::operator() does suspend current context and resumes
>>> context represented by the execution_context
>>>
>>
>>>
>>>
>>>> You then need to transfer control to someone else who may asychronously
>>>> resume that context's execution.
>>>>
>>>
>>> no, that's a false assumption - there is no 'someone else' the execution
>>> control is transferred from context ctx1 to context ctx2
>>>
>>
>> Well, I didn't think this was going to get so pedantic, or I would have
>> used terminology more carefully. That's my fault; *every* discussion of
>> coroutines ends in pedantry.
>>
>
> amen!
>
>
>>
>> So allow me to restate this more formally, using P0099's terminology:
>>
>> 1. The current execution_context must cease executing.
>> 2. The previously executing context `ctx1` now needs to be handed off to
>> whomever will continue it.
>> 3. Some other execution_context `ctx2` now needs to be resumed,
>> presumably with some information about how to ask if `ctx1` has finished or
>> has new data or whatever.
>>
>> And these things must happen in this order.
>>
>> The problem I pointed out is this: what execution context is running
>> after step 1, which executes the code needed for step 2?
>>
>> See, the problem is this. I want to stop executing and give my context to
>> someone else who will then resume my execution. How do I do that? Under
>> naive use of P0099, you'd do this:
>>
>> SomeoneElse(execution_context::current()); //Gives my context to someone
>> else.
>> //Setup promise/future/whatever interface to `ctx2`.
>> ctx2(); //Start up a different context.
>>
>> This can work... so long as `SomeoneElse` does not attempt to
>> *immediately* resume the context I give it. And by "immediately", I mean
>> "before I call `ctx2()`".
>>
>> Now, you might say that this is incredibly silly. Nobody would write
>> `SomeoneElse` in a way that would instantly resume the execution_context it
>> was given.
>>
>> Well the fact is... they can. Because they may not have a choice in the
>> matter. If `SomeoneElse` is an asynchronous function call (AKA,
>> *everything* in the Networking TS), then we have a scheduling problem.
>> Furthermore, it is not a scheduling problem that can easily be sorted out,
>> since there is no way to say, "wait until this execution_context has
>> finished executing."
>>
>> That's a problem, and it is not one that can easily be solved. The only
>> way I can see how to solve it is like this:
>>
>> //Setup promise/future/etc interface to `ctx2`.
>>
>> execution_context temp{[=](execution_context old)
>> {
>> SomeoneElse(old);
>> ctx2(); //Invoke ctx2.
>> }, execution_context::current()};
>>
>> temp();
>>
>> You have to create a *whole execution context*, just to do a simple
>> switch. I'm sure you can get rid of the local creation of this context. You
>> could have some thread_local context that you create with a minimal stack,
>> who's purpose is to do this kind of switching. But the fact is, you're
>> still having to do two context switches: once to the intermediary context,
>> and one to the final destination.
>>
>> You *cannot* do with just the initial and final contexts; you need that
>> third context in there that acts as an intermediary.
>>
>
> FWIW, me and Oliver discussed this extensively a few months ago. As a
> recap, what I proposed is something like this:
>
> yield_with(ctx2, [](auto ctx) { SomeoneElse(move(ctx)); return ctx; });
>
> Only one context switch is needed. Yield_with can be implemented on top of
> P0099, but builtin support would be better.
>
How exactly would `yield_with` be implemented on top of P0099?
> The whole point of P0057 continuations are that you can write
>> continuations that don't *look like* continuations. Normally,
>> continuations have to involve lambdas, where you do this:
>>
>> void func()
>> {
>> //First part of funciton
>> auto test = PossiblyAsyncTask([=](auto val) {/*Rest of my function*/});
>>
>> while(!test.IsFinished())
>> //Do some stuff.
>> }
>>
>>
> That's not really a proper first-class continuation. That's simulating a
> continuation by manual-rewriting with a lambda.
>
Well... yes. That was my point. With the language as is in C++14, that's
the best you can do.
P0057 makes such constructs more palatable and readable. P0099 improves
things relative to C++14, but it is still not as readable as P0057.
I'd say my biggest concern with P0099 for continuations is that it's not
clear exactly what the scope of the continuation is, how far the
asynchronous continuation part can reach. P0057's scope is very well
founded: that function. The immediate caller of the function is passed a
return value that expresses the fact that the function will not necessarily
return the value immediately.
For cases like generators, I find the scope limitation of P0057 to be...
highly annoying. Using P0057 for generators is basically a gigantic hack on
the feature. If you removed the ability to make generators from P0057, odds
are good you'd reduce its complexity by 60+%.
However, for genuine continuation-style programming (which generators are
not), I think the limitations of P0057's scope are acceptable. While you
can be sure that your current function is able to deal with
possibly-asynchronous issues, you can't be sure that your immediate caller
(and *their* immediate caller, all the way down to whomever started your
context) can handle them too.
My concern is that with P0099, we'll be seeing a lot of this:
future<int> MyContinueFunc(...)
{
//Context we return control to. IE: our caller.
execution_context ret_ctx = execution_context::current();
//Pointer to the new context we will create, which we use for our async
call.
auto func = [=](promise<int> prom, ...)
{
//Actual function that has continuations.
yield_with(ret_ctx, [](auto ctx) { AsyncCall(move(ctx)); return ctx;})
//After continuation
prom.set(value);
}
promise<int> prom;
future<int> ret = prom.get_future();
execution_context ec(func, std::move(prom), ...);
ec();
return ret;
}
This is a huge amount of boilerplate for something that P0057 handles with
minimal effort. Maybe you can wrap all this boilerplate up into a
(template) function call. But you would still have to write a function
within a function:
future<int> MyContinueFunc()
{
//The promise is created internally, owned by the immediate caller to
this function.
//The promise type is the return type of the given function.
//The return type of `context_continue` is a future connected to the
promise.
return context_continue([](execution_context ret_ctx, ...)
{
//Actual function that has continuations.
yield_with(ret_ctx, [](auto ctx) { AsyncCall(move(ctx)); return ctx;})
//After continuation
return value;
};
}
And the thing is, because P0099 is symmetric, it doesn't even really make
this code more flexible by allowing multiple levels of stacks to continue
with `yield_with`. Why? Because `ret_ctx` isn't available to code that the
lambda calls, unless it explicitly passes it. In which case, that code must
be explicitly designed to yield to a particular location. So you can't
transparently `yield_with` through functions that have no idea this sort of
continuation is going on.
Not without a global/thread_local variable of some kind that would hold
`ret_ctx`'s value.
It is like simulating a for loop with goto and if statements. Stackful
> coroutines (both symmetric and asymmetric) are in fact equivalent to first
> class one shot delimited continuation.
>
Equivalent in functionality, yes. But not in code niceness, as shown above.
P0099 is a good, low-level tool, and whether we get P0057 or not, we *need*
P0099 or something very similar to it. But continuations are a higher-level
tool. And having language support for continuations makes
continuation-based code look a lot more reasonable.
I think of P0099 like function pointers, while P0057 is like virtual
functions. The latter is clearly higher-level than the former, and you need
the former to implement the latter. But having support for the higher-level
one makes the common use case much easier to use.
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1391_1077262577.1454525793953
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 2, 2016 at 7:31:57 PM UTC-5, Giovanni=
Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Tuesday, February 2, 2016 at 8:18:06 PM UTC, Nicol Bolas wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">BTW, I hope to see=
an updated P0099 revision or something similar for Jacksonville.<br><br>On=
Tuesday, February 2, 2016 at 10:58:42 AM UTC-5, Oliver Kowalke wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote">2016-02-02 16:30 GMT+01:00 Nicol Bolas <span dir=3D"ltr"><<a re=
l=3D"nofollow">jmck...@gmail.com</a>></span>:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><span>On Tuesday, February 2, 2016 at 2:47:36 AM U=
TC-5, Oliver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">P099R0 (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2015/p0099r0.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"thi=
s.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\46sa\75D\46sntz\07=
51\46usg\75AFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.o=
rg%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\46sa\75D\46snt=
z\0751\46usg\75AFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true;">http:/=
/www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>p0099r0.pdf</a>=
) - allows to build coroutines, fibers and shift/reset operators on top of =
it<br></div></blockquote></span><div>=C2=A0<br>In order to continue the exe=
cution of a function (ie: what P0057's `co_await` does), you have to do=
all of the following operations:<br><br>1. Halt the current execution.<br>=
2. Transfer scheduling of the continuation to someone else.<br>3. Return co=
ntrol of the current thread to whomever it is that should get it.<br></div>=
</div></blockquote><div><br>P099R0 does not involve threads and or schedule=
r(s)<br></div><div>execution_context::operator() does suspend current conte=
xt and resumes context represented by the execution_context<br></div></div>=
</div></div></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">=
<div><br></div></blockquote><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div>You then need to transfer c=
ontrol to someone else who may asychronously resume that context's exec=
ution.</div></div></blockquote><div><br></div><div>no, that's a false a=
ssumption - there is no 'someone else' the execution control is tra=
nsferred from context ctx1 to context ctx2<br></div></div></div></div></blo=
ckquote><div><br>Well, I didn't think this was going to get so pedantic=
, or I would have used terminology more carefully. That's my fault; <i>=
every</i> discussion of coroutines ends in pedantry.<br></div></div></block=
quote><div><br>amen!<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><br>So allow me to restate this more formally, using=
P0099's terminology:<br><br>1. The current execution_context must ceas=
e executing.<br>2. The previously executing context `ctx1` now needs to be =
handed off to whomever will continue it.<br>3. Some other execution_context=
`ctx2` now needs to be resumed, presumably with some information about how=
to ask if `ctx1` has finished or has new data or whatever.<br><br>And thes=
e things must happen in this order.<br><br>The problem I pointed out is thi=
s: what execution context is running after step 1, which executes the code =
needed for step 2?<br><br>See, the problem is this. I want to stop executin=
g and give my context to someone else who will then resume my execution. Ho=
w do I do that? Under naive use of P0099, you'd do this:<br><br><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px;word-wrap:break-word"><code><div><span styl=
e=3D"color:#606">SomeoneElse</span><span style=3D"color:#660">(</span><span=
style=3D"color:#000">execution_context</span><span style=3D"color:#660">:<=
wbr>:</span><span style=3D"color:#000">current</span><span style=3D"color:#=
660">());</span><span style=3D"color:#000"> </span><span style=3D"color:#80=
0">//Gives my context to someone else.</span><span style=3D"color:#000"><br=
></span><span style=3D"color:#800">//Setup promise/future/whatever interfac=
e to `ctx2`.</span><span style=3D"color:#000"><br>ctx2</span><span style=3D=
"color:#660">();</span><span style=3D"color:#000"> =C2=A0</span><span style=
=3D"color:#800">//Start up a different context.</span><span style=3D"color:=
#000"><br></span></div></code></div><br>This can work... so long as `Someon=
eElse` does not attempt to <i>immediately</i> resume the context I give it.=
And by "immediately", I mean "before I call `ctx2()`".=
<br><br>Now, you might say that this is incredibly silly. Nobody would writ=
e `SomeoneElse` in a way that would instantly resume the execution_context =
it was given.<br><br>Well the fact is... they can. Because they may not hav=
e a choice in the matter. If `SomeoneElse` is an asynchronous function call=
(AKA, <i>everything</i> in the Networking TS), then we have a scheduling p=
roblem. Furthermore, it is not a scheduling problem that can easily be sort=
ed out, since there is no way to say, "wait until this execution_conte=
xt has finished executing."<br><br>That's a problem, and it is not=
one that can easily be solved. The only way I can see how to solve it is l=
ike this:<br><br><div style=3D"background-color:rgb(250,250,250);border-col=
or:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wor=
d"><code><div><span style=3D"color:#800">//Setup promise/future/etc interfa=
ce to `ctx2`.</span><span style=3D"color:#000"><br><br>execution_context te=
mp</span><span style=3D"color:#660">{[=3D](</span><span style=3D"color:#000=
">execution_context old</span><span style=3D"color:#660">)</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#606">SomeoneElse</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#000">old</span=
><span style=3D"color:#660">);</span><span style=3D"color:#000"><br>=C2=A0 =
ctx2</span><span style=3D"color:#660">();</span><span style=3D"color:#000">=
</span><span style=3D"color:#800">//Invoke ctx2.</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#660">},</span><span style=3D"color=
:#000"> execution_context</span><span style=3D"color:#660">::</span><span s=
tyle=3D"color:#000">current</span><span style=3D"color:#660">()};</span><sp=
an style=3D"color:#000"><br><br>temp</span><span style=3D"color:#660">();</=
span></div></code></div><br>You have to create a <i>whole execution context=
</i>, just to do a simple switch. I'm sure you can get rid of the local=
creation of this context. You could have some thread_local context that yo=
u create with a minimal stack, who's purpose is to do this kind of swit=
ching. But the fact is, you're still having to do two context switches:=
once to the intermediary context, and one to the final destination.<br><br=
>You <i>cannot</i> do with just the initial and final contexts; you need th=
at third context in there that acts as an intermediary.<br></div></div></bl=
ockquote><div><br>FWIW, me and Oliver discussed this extensively a few mont=
hs ago. As a recap, what=C2=A0 I proposed is something like this:<br>=C2=A0=
<br>=C2=A0 yield_with(ctx2, [](auto ctx) { SomeoneElse(move(ctx)); return c=
tx; });<br><br>Only one context switch is needed. Yield_with can be impleme=
nted on top of P0099, but builtin support would be better.<br></div></div><=
/blockquote><div><br>How exactly would `yield_with` be implemented on top o=
f P0099?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>The whole point of P0057 continuations are that you can write cont=
inuations that don't <i>look like</i> continuations. Normally, continua=
tions have to involve lambdas, where you do this:<br><br><div style=3D"back=
ground-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:so=
lid;border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:=
#008">void</span><span style=3D"color:#000"> func</span><span style=3D"colo=
r:#660">()</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"=
color:#800">//First part of funciton</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#008">auto</span><span style=3D"color:#0=
00"> test </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> </span><span style=3D"color:#606">PossiblyAsyncTask</span><span styl=
e=3D"color:#660">([=3D](</span><span style=3D"color:#008">auto</span><span =
style=3D"color:#000"> val</span><span style=3D"color:#660">)</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#800">/*Rest of my function*/</span><span style=3D"color:#660">})=
;</span><span style=3D"color:#000"><br><br>=C2=A0 </span><span style=3D"col=
or:#008">while</span><span style=3D"color:#660">(!</span><span style=3D"col=
or:#000">test</span><span style=3D"color:#660">.</span><span style=3D"color=
:#606">IsFinished</span><span style=3D"color:#660">())</span><span style=3D=
"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#800">//Do some =
stuff.</span><span style=3D"color:#000"><br></span><span style=3D"color:#66=
0">}</span></div></code></div><br></div></div></blockquote><div><br>That=
9;s not really a proper first-class continuation. That's simulating a c=
ontinuation by manual-rewriting with a lambda.</div></div></blockquote><div=
><br>Well... yes. That was my point. With the language as is in C++14, that=
's the best you can do.<br><br>P0057 makes such constructs more palatab=
le and readable. P0099 improves things relative to C++14, but it is still n=
ot as readable as P0057.<br><br>I'd say my biggest concern with P0099 f=
or continuations is that it's not clear exactly what the scope of the c=
ontinuation is, how far the asynchronous continuation part can reach. P0057=
's scope is very well founded: that function. The immediate caller of t=
he function is passed a return value that expresses the fact that the funct=
ion will not necessarily return the value immediately.<br><br>For cases lik=
e generators, I find the scope limitation of P0057 to be... highly annoying=
.. Using P0057 for generators is basically a gigantic hack on the feature. I=
f you removed the ability to make generators from P0057, odds are good you&=
#39;d reduce its complexity by 60+%.<br><br>However, for genuine continuati=
on-style programming (which generators are not), I think the limitations of=
P0057's scope are acceptable. While you can be sure that your current =
function is able to deal with possibly-asynchronous issues, you can't b=
e sure that your immediate caller (and <i>their</i> immediate caller, all t=
he way down to whomever started your context) can handle them too.<br><br>M=
y concern is that with P0099, we'll be seeing a lot of this:<br><br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">future</span><s=
pan style=3D"color: #080;" class=3D"styled-by-prettify"><int></span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">MyContinueFunc</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(...)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">//Context we return control to. IE: our ca=
ller.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 execution_context ret_ctx </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> execution_context</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">current</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br>=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">//Pointer to the new context we will create, which we use for o=
ur async call.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> func </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[=3D](promise<int> pro=
m</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><code cla=
ss=3D"prettyprint"><span style=3D"color: #080;" class=3D"styled-by-prettify=
">, </span></code>...)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">//Actual function that has continuations.</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 yield_with</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><code =
class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">ret_ctx</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"></span></code><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> ctx</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>AsyncCall</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">move</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">ctx</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> ctx</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;})</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">//After continuation</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 prom</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">set</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">value</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
br></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><code c=
lass=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">=C2=A0 promise<int> prom;</span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify"><br></span></code>=C2=A0 future</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> ret </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> prom</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">get_future</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 execution_context ec</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">func</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">std::move(prom), ...);</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 ec</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> ret</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></=
div></code></div><br>This is a huge amount of boilerplate for something tha=
t P0057 handles with minimal effort. Maybe you can wrap all this boilerplat=
e up into a (template) function call. But you would still have to write a f=
unction within a function:<br><br><div class=3D"prettyprint" style=3D"backg=
round-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-s=
tyle: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">future</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify"><int></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">MyContinueFunc</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//The =
promise is created internally, owned by the immediate caller to this functi=
on.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//The =
promise type is the return type of the given function.</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//The return type of `contex=
t_continue` is a future connected to the promise.</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> context_continue</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">([](</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify">execution_context ret_ctx</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">...)</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">//Actual function that has continuations.</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 yield_with</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ret_c=
tx</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> ctx</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">AsyncC=
all</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">move</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">ctx</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">));</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> ctx</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;})</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"styled-b=
y-prettify">//After continuation</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> value</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">}</span></div></code></div><br>And the thing is, because P0099 is symmetr=
ic, it doesn't even really make this code more flexible by allowing mul=
tiple levels of stacks to continue with `yield_with`. Why? Because `ret_ctx=
` isn't available to code that the lambda calls, unless it explicitly p=
asses it. In which case, that code must be explicitly designed to yield to =
a particular location. So you can't transparently `yield_with` through =
functions that have no idea this sort of continuation is going on.<br><br>N=
ot without a global/thread_local variable of some kind that would hold `ret=
_ctx`'s value.<br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div> It is like simulating a for loop with goto and if =
statements. Stackful coroutines (both symmetric and asymmetric) are in fact=
equivalent to first class one shot delimited continuation.<br></div></div>=
</blockquote><div><br>Equivalent in functionality, yes. But not in code nic=
eness, as shown above.<br><br>P0099 is a good, low-level tool, and whether =
we get P0057 or not, we <i>need</i> P0099 or something very similar to it. =
But continuations are a higher-level tool. And having language support for =
continuations makes continuation-based code look a lot more reasonable.<br>=
<br>I think of P0099 like function pointers, while P0057 is like virtual fu=
nctions. The latter is clearly higher-level than the former, and you need t=
he former to implement the latter. But having support for the higher-level =
one makes the common use case much easier to use.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1391_1077262577.1454525793953--
------=_Part_1390_109409642.1454525793951--
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Thu, 4 Feb 2016 19:15:47 -0500
Raw View
--Apple-Mail=_1414930B-8112-45E6-B0DD-4ACF0D5560AB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On Feb 2, 2016, at 11:14 AM, std-proposals@isocpp.org wrote:
>=20
> std-proposals@isocpp.org <https://groups.google.com/a/isocpp.org/forum/?u=
tm_source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics> Google G=
roups <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&ut=
m_medium=3Demail/#!overview> <https://groups.google.com/a/isocpp.org/forum=
/?utm_source=3Ddigest&utm_medium=3Demail/#!overview> =20
> Topic digest <>
> View all topics <https://groups.google.com/a/isocpp.org/forum/?utm_source=
=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics>
> Continuations for C++? <x-msg://10/#group_thread_0> - 7 Updates
> (snipped=E2=80=A6)
> <>Continuations for C++? <http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/t/e0c81dd2c5d4d5d4?utm_source=3Ddigest&utm_medium=3Demail>=
=20
> (snipped=E2=80=A6)
> (snipped=E2=80=A6)
> (snipped=E2=80=A6)
> Nicol Bolas <jmckesson@gmail.com>: Feb 01 08:25PM -0800=20
>=20
> On Monday, February 1, 2016 at 5:26:53 PM UTC-5, Bryce Glover wrote:
> > expose the continuation-passing mechanisms upon which it will be built?=
I=20
> > think that it might be useful for users to be able to build things on t=
op=20
> > of them.
> =20
> If you're talking about P0057 <http://wg21.link/P0057 <http://wg21.link/P=
0057>>-style coroutines,=20
> not really. The idea of that coroutine proposal is to allow the=20
> continuation of *the rest of your function*. That is, instead of passing =
a=20
> function which will be continued by some process, you write your code as =
if=20
> it were normal, non-continuation code. The `co_await` operator will=20
> transmit your current function's execution to whomever it is that will=20
> "schedule" its continuation (depending on the value of the expression and=
a=20
> *truly* dizzying array of customization points).
> =20
> But it's not something you could just shove a random function at and tell=
=20
> it to continue it. Well, given how ludicrously customizable it is, you=20
> could probably make it work that way. But that's not what it's *for*.
> Oliver Kowalke <oliver.kowalke@gmail.com>: Feb 02 08:47AM +0100=20
>=20
> P099R0 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.p=
df <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>)
> - allows to build coroutines, fibers and shift/reset operators on top of =
it
> =20
> Nicol Bolas <jmckesson@gmail.com>: Feb 02 07:30AM -0800=20
>=20
> On Tuesday, February 2, 2016 at 2:47:36 AM UTC-5, Oliver Kowalke wrote:
> =20
> > P099R0 (
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf <ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>) -=20
> > allows to build coroutines, fibers and shift/reset operators on top of =
it
> =20
> I like P0099 (a lot), but I don't think it's a very good system for=20
> *continuation*-style APIs. The reason being the difficulty in doing the=
=20
> continuation part.
> =20
> In order to continue the execution of a function (ie: what P0057's=20
> `co_await` does), you have to do all of the following operations:
> =20
> 1. Halt the current execution.
> 2. Transfer scheduling of the continuation to someone else.
> 3. Return control of the current thread to whomever it is that should get=
=20
> it.
> =20
> In many cases, this is trivial with P0099. The case of generators, for=20
> example, works fine. But it works fine because the code that schedules th=
e=20
> resumption of the function is also the code you are returning to. So it i=
s=20
> impossible for the coroutine to be resumed before you've transferred=20
> control elsewhere.
> =20
> P0057 is designed for cases where 2 and 3 are *different*. Where you're=
=20
> firing off some potentially-asynchronous process that will execute=20
> independently of the code that will receive the value.
> =20
> The issue that P0099 has with this is scenario is that, in order to make=
=20
> the potentially-asynchronous code work, you *must* do the items in the=20
> order I outlined them above. That is, you need to halt the current=20
> context's execution, such that after step 1, it is legal to continue its=
=20
> execution. You then need to transfer control to someone else who may=20
> asychronously resume that context's execution. That's why #1 has to happe=
n=20
> *first*; if #2 fires off a thread, you can't be sure that the thread won'=
t=20
> resume your function before you've finished with #3.
> =20
> In order to do that with P0099, you need a third execution context. One=
=20
> that is not part of the call stack of the continuation itself. This means=
=20
> that step 1 halts its own context and starts up the external one; this=20
> means that the context is ready to be continued. And therefore, both step=
s=20
> 1 and 3 require a context switch. And while these are not an onerous=20
> burden, they aren't exactly *free* either. So it's not impossible to=20
> implement, but this style of programming has quite a bit of overhead. Als=
o,=20
> P0099 doesn't have any systems in place to help with this, so you'll have=
=20
> to build this machinery yourself.
> =20
> I hope you're good at async programming, because it's *really* easy to ge=
t=20
> wrong.
> =20
> By contrast, P0057 does things correctly by default. Of course it does;=
=20
> P0057 is *all about* continuation-based programming. That's what it's for=
,=20
> so it does it very well. P0099 is really designed for generalized stack=
=20
> manipulation. So specialized use cases require specific fiddling and so=
=20
> forth.
> Oliver Kowalke <oliver.kowalke@gmail.com>: Feb 02 04:58PM +0100=20
>=20
> > 2. Transfer scheduling of the continuation to someone else.
> > 3. Return control of the current thread to whomever it is that should g=
et
> > it.
> =20
> P099R0 does not involve threads and or scheduler(s)
> execution_context::operator() does suspend current context and resumes
> context represented by the execution_context
> =20
> =20
> > You then need to transfer control to someone else who may asychronously
> > resume that context's execution.
> =20
> no, that's a false assumption - there is no 'someone else' the execution
> control is transferred from context ctx1 to context ctx2
> =20
> =20
> > That's why #1 has to happen *first*; if #2 fires off a thread,
> =20
> again, no threads are required
> =20
> =20
> > In order to do that with P0099, you need a third execution context.
> =20
> not correct
> =20
> one benefit of P099R0 over P057 is, that it provides symmetric context
> switch while P057 is only about asymmetric
> symmetric: the next context is arbitrary
> asymmetric: control must be transferred back to caller
> Back to top <x-msg://10/#digest_top> <>(snipped=E2=80=A6)
> You received this digest because you're subscribed to updates for this gr=
oup. You can change your settings on the group membership page <https://gro=
ups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!=
forum/std-proposals/join>.
> To unsubscribe from this group and stop receiving emails from it send an =
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubsc=
ribe@isocpp.org>.
> On Feb 3, 2016, at 2:02 PM, std-proposals@isocpp.org wrote:
>=20
> std-proposals@isocpp.org <https://groups.google.com/a/isocpp.org/forum/?u=
tm_source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics> Google G=
roups <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&ut=
m_medium=3Demail/#!overview> <https://groups.google.com/a/isocpp.org/forum=
/?utm_source=3Ddigest&utm_medium=3Demail/#!overview> =20
> Topic digest=C2=A0 <>
> View all topics <https://groups.google.com/a/isocpp.org/forum/?utm_source=
=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics>
> Continuations for C++? <x-msg://13/#group_thread_0> - 3 Updates
> (snipped=E2=80=A6)
> <>Continuations for C++?=C2=A0 =C2=A0 =C2=A0 <http://groups.google.com/a=
/isocpp.org/group/std-proposals/t/e0c81dd2c5d4d5d4?utm_source=3Ddigest&utm_=
medium=3Demail> =20
> Giovanni Piero Deretta <gpderetta@gmail.com>: Feb 02 04:31PM -0800=20
>=20
> On Tuesday, February 2, 2016 at 8:18:06 PM UTC, Nicol Bolas wrote:
> =20
> > Well, I didn't think this was going to get so pedantic, or I would have=
=20
> > used terminology more carefully. That's my fault; *every* discussion of=
=20
> > coroutines ends in pedantry.
> =20
> amen!
>=20
> =20
> > and one to the final destination.
> =20
> > You *cannot* do with just the initial and final contexts; you need that=
=20
> > third context in there that acts as an intermediary.
> =20
> FWIW, me and Oliver discussed this extensively a few months ago. As a=20
> recap, what I proposed is something like this:
>=20
> yield_with(ctx2, [](auto ctx) { SomeoneElse(move(ctx)); return ctx; });
> =20
> Only one context switch is needed. Yield_with can be implemented on top o=
f=20
> P0099, but builtin support would be better.
> =20
> =20
> >> asymmetric: control must be transferred back to caller
> =20
> > Yes, but you're just proving my point. Symmetric coroutines are not=20
> > *continuations*.
> =20
> They are actually.
>=20
> =20
> =20
> > while(!test.IsFinished())
> > //Do some stuff.
> > }
> =20
> That's not really a proper first-class continuation. That's simulating a=
=20
> continuation by manual-rewriting with a lambda. It is like simulating a f=
or=20
> loop with goto and if statements. Stackful coroutines (both symmetric and=
=20
> asymmetric) are in fact equivalent to first class one shot delimited=20
> continuation.=20
> =20
> -- gpd
> Oliver Kowalke <oliver.kowalke@gmail.com>: Feb 03 08:55AM +0100=20
>=20
>=20
> > BTW, I hope to see an updated P0099 revision or something similar for
> > Jacksonville.
> =20
> maybe
> =20
> <snip>
> see Giovanni's comment
> =20
> But because the OP asked "...useful for users to be able to build things =
on
> top of them..." - I believe that the mechanisms described in P099 are
> suitable to build high-level abstractions (as demonstrated in some boost
> libraries).
> Nicol Bolas <jmckesson@gmail.com>: Feb 03 10:56AM -0800=20
>=20
> On Tuesday, February 2, 2016 at 7:31:57 PM UTC-5, Giovanni Piero Deretta=
=20
> wrote:
> =20
> > yield_with(ctx2, [](auto ctx) { SomeoneElse(move(ctx)); return ctx; });
> =20
> > Only one context switch is needed. Yield_with can be implemented on top=
of=20
> > P0099, but builtin support would be better.
> =20
> How exactly would `yield_with` be implemented on top of P0099?
>=20
> =20
> >> }
> =20
> > That's not really a proper first-class continuation. That's simulating =
a=20
> > continuation by manual-rewriting with a lambda.
> =20
> Well... yes. That was my point. With the language as is in C++14, that's=
=20
> the best you can do.
> =20
> P0057 makes such constructs more palatable and readable. P0099 improves=
=20
> things relative to C++14, but it is still not as readable as P0057.
> =20
> I'd say my biggest concern with P0099 for continuations is that it's not=
=20
> clear exactly what the scope of the continuation is, how far the=20
> asynchronous continuation part can reach. P0057's scope is very well=20
> founded: that function. The immediate caller of the function is passed a=
=20
> return value that expresses the fact that the function will not necessari=
ly=20
> return the value immediately.
> =20
> For cases like generators, I find the scope limitation of P0057 to be...=
=20
> highly annoying. Using P0057 for generators is basically a gigantic hack =
on=20
> the feature. If you removed the ability to make generators from P0057, od=
ds=20
> are good you'd reduce its complexity by 60+%.
> =20
> However, for genuine continuation-style programming (which generators are=
=20
> not), I think the limitations of P0057's scope are acceptable. While you=
=20
> can be sure that your current function is able to deal with=20
> possibly-asynchronous issues, you can't be sure that your immediate calle=
r=20
> (and *their* immediate caller, all the way down to whomever started your=
=20
> context) can handle them too.
> =20
> My concern is that with P0099, we'll be seeing a lot of this:
> =20
> future<int> MyContinueFunc(...)
> {
> //Context we return control to. IE: our caller.
> execution_context ret_ctx =3D execution_context::current();
> =20
> //Pointer to the new context we will create, which we use for our async=
=20
> call.
> auto func =3D [=3D](promise<int> prom, ...)
> {
> //Actual function that has continuations.
> yield_with(ret_ctx, [](auto ctx) { AsyncCall(move(ctx)); return ctx;})
> //After continuation
> prom.set(value);
> }
> =20
> promise<int> prom;
> future<int> ret =3D prom.get_future();
> execution_context ec(func, std::move(prom), ...);
> ec();
> return ret;
> }
> =20
> This is a huge amount of boilerplate for something that P0057 handles wit=
h=20
> minimal effort. Maybe you can wrap all this boilerplate up into a=20
> (template) function call. But you would still have to write a function=20
> within a function:
> =20
> future<int> MyContinueFunc()
> {
> //The promise is created internally, owned by the immediate caller to=20
> this function.
> //The promise type is the return type of the given function.
> //The return type of `context_continue` is a future connected to the=20
> promise.
> return context_continue([](execution_context ret_ctx, ...)
> {
> //Actual function that has continuations.
> yield_with(ret_ctx, [](auto ctx) { AsyncCall(move(ctx)); return ctx;})
> //After continuation
> return value;
> };
> }
> =20
> And the thing is, because P0099 is symmetric, it doesn't even really make=
=20
> this code more flexible by allowing multiple levels of stacks to continue=
=20
> with `yield_with`. Why? Because `ret_ctx` isn't available to code that th=
e=20
> lambda calls, unless it explicitly passes it. In which case, that code mu=
st=20
> be explicitly designed to yield to a particular location. So you can't=20
> transparently `yield_with` through functions that have no idea this sort =
of=20
> continuation is going on.
> =20
> Not without a global/thread_local variable of some kind that would hold=
=20
> `ret_ctx`'s value.
> =20
> It is like simulating a for loop with goto and if statements. Stackful=20
> > coroutines (both symmetric and asymmetric) are in fact equivalent to fi=
rst=20
> > class one shot delimited continuation.
> =20
> Equivalent in functionality, yes. But not in code niceness, as shown abov=
e.
> =20
> P0099 is a good, low-level tool, and whether we get P0057 or not, we *nee=
d*=20
> P0099 or something very similar to it. But continuations are a higher-lev=
el=20
> tool. And having language support for continuations makes=20
> continuation-based code look a lot more reasonable.
> =20
> I think of P0099 like function pointers, while P0057 is like virtual=20
> functions. The latter is clearly higher-level than the former, and you ne=
ed=20
> the former to implement the latter. But having support for the higher-lev=
el=20
> one makes the common use case much easier to use.
> Back to top <x-msg://13/#digest_top> <>(snipped=E2=80=A6)
> You received this digest because you're subscribed to updates for this gr=
oup. You can change your settings on the group membership page <https://gro=
ups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!=
forum/std-proposals/join>.
> To unsubscribe from this group and stop receiving emails from it send an =
email to std-proposals+unsubscribe@isocpp.org <mailto:std-proposals+unsubsc=
ribe@isocpp.org>.
>=20
@Nicol Bolas: =20
> If you're talking about P0057 <http://wg21.link/P0057 <http://wg21.link/P=
0057>>-style coroutines,=20
> not really. The idea of that coroutine proposal is to allow the=20
> continuation of *the rest of your function*. That is, instead of passing =
a=20
> function which will be continued by some process, you write your code as =
if=20
> it were normal, non-continuation code. The `co_await` operator will=20
> transmit your current function's execution to whomever it is that will=20
> "schedule" its continuation (depending on the value of the expression and=
a=20
> *truly* dizzying array of customization points).
> =20
> But it's not something you could just shove a random function at and tell=
=20
> it to continue it. Well, given how ludicrously customizable it is, you=20
> could probably make it work that way. But that's not what it's *for*.
OK, thanks for clarifying that! =20
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93
@Oliver Kowalke: =20
> P099R0 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.p=
df <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>)
> - allows to build coroutines, fibers and shift/reset operators on top of =
it
Come to think of it, that=E2=80=99s actually probably more along the lines =
of what I was thinking about in the first place. =20
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93
@Nicol Bolas, @Oliver Kowalke, @Giovanni Piero Deretta: =20
All of these points that you=E2=80=99ve all raised are very insightful. I =
look forward to seeing progress in this area! =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.
--Apple-Mail=_1414930B-8112-45E6-B0DD-4ACF0D5560AB
Content-Type: multipart/related;
type="text/html";
boundary="Apple-Mail=_A840FC09-E6DA-40FD-96CC-B0D792FE79BC"
--Apple-Mail=_A840FC09-E6DA-40FD-96CC-B0D792FE79BC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D"">On Feb 2, 2016, at 11:14 AM, <a hre=
f=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposals@isocpp.org</=
a> wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D"">
<div style=3D"border: 1px solid rgb(211, 211, 211); max-width: 850px; font-=
family: Arial, sans-serif;" class=3D"">
<div style=3D"background-color:#f5f5f5;padding:10px 20px" class=3D"">
<table cellpadding=3D"0" cellspacing=3D"0" style=3D"width:100%" class=
=3D"">
<tbody class=3D"">
<tr class=3D"">
<td style=3D"width:70%" class=3D"">
<span style=3D"font:18px/20px arial;color:#333333" class=3D"">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_=
source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics" style=
=3D"text-decoration:none; color:#333333" class=3D"">
std-proposals@isocpp.org</a>
</span>
</td>
<td style=3D"text-align:right;width:30%" class=3D"">
<span style=3D"font:20px/24px arial" class=3D""><a style=3D"col=
or:#dd4b39; text-decoration:none;" href=3D"https://groups.google.com/a/isoc=
pp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail/#!overview" target=
=3D"_blank" class=3D"">Google Groups</a></span>
</td>
<td style=3D"width:32px;" class=3D"">
<a href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_so=
urce=3Ddigest&utm_medium=3Demail/#!overview" target=3D"_blank" class=3D=
""><img style=3D"border:0;vertical-align:middle" src=3D"http://www.google.c=
om/images/icons/product/groups-32.png" class=3D""></a>
</td>
</tr>
</tbody>
</table>
</div>
<div style=3D"padding:20px; background-color: #f5f5f5;" class=3D"">
<div style=3D"font-family: arial; color: #222222; padding: 0px" class=3D"">
<a name=3D"digest_top" style=3D"font-size:21px;" class=3D"">
=20
=20
Topic digest
=20
</a><br class=3D"">
<span style=3D"font-size:11px" class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"https://groups.=
google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!=
forum/std-proposals/topics" class=3D"">View all topics</a>
</span>
</div>
<div style=3D"font: 13px/18px arial; color:#222222; padding: 0px; margin-bo=
ttom:30px" class=3D"">
<ul style=3D"margin-left:3px; padding-left:0px" class=3D"">
=20
<li class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"x-msg://10/#g=
roup_thread_0" class=3D"">
Continuations for C++?</a> -
<span style=3D"color:#777777" class=3D"">7 Updates</span>
</li>
=20
<li class=3D"">(snipped=E2=80=A6)</li>
=20
</ul>
</div>
=20
<a name=3D"group_thread_0" class=3D""></a>
<div style=3D"display:inline-block; font-family: arial; padding: 4px 0 5p=
x 0px;" class=3D"">
=20
<a target=3D"_blank" href=3D"http://groups.google.com/a/isocpp.org/grou=
p/std-proposals/t/e0c81dd2c5d4d5d4?utm_source=3Ddigest&utm_medium=3Dema=
il" style=3D"font-size:21px; color:#1155CC; text-decoration:none" class=3D"=
">
Continuations for C++?
</a>
=20
</div>
<table style=3D"border-collapse: collapse; width: 100%" class=3D"">
=20
<tbody class=3D""><tr class=3D""><td style=3D"background-color: rgb(2=
55, 255, 255); font-family: arial; padding: 10px 15px; border: 1px solid rg=
b(211, 211, 211);" class=3D""><font color=3D"#b1b0b0" class=3D""><span styl=
e=3D"font-size: 15px;" class=3D"">(snipped=E2=80=A6)</span></font></td></tr=
>
=20
<tr class=3D""><td style=3D"background-color: rgb(255, 255, 255); fon=
t-family: arial; padding: 10px 15px; border: 1px solid rgb(211, 211, 211);"=
class=3D""><font color=3D"#b1b0b0" class=3D""><span style=3D"font-size: 15=
px;" class=3D"">(snipped=E2=80=A6)</span></font></td></tr>
=20
<tr class=3D""><td style=3D"background-color: rgb(255, 255, 255); fon=
t-family: arial; padding: 10px 15px; border: 1px solid rgb(211, 211, 211);"=
class=3D""><font color=3D"#b1b0b0" class=3D""><span style=3D"font-size: 15=
px;" class=3D"">(snipped=E2=80=A6)</span></font></td></tr>
=20
<tr class=3D""><td style=3D"background-color: #FFFFFF; color:#2E2E2E;=
font-family: arial; padding:10px 15px; border:1px solid #d3d3d3;" class=3D=
"">
<span style=3D"color:#B1B0B0; font-size: 15px;" class=3D"">
Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com" class=3D""=
>jmckesson@gmail.com</a>>: Feb 01 08:25PM -0800
</span>
<br class=3D""><br class=3D"">
On Monday, February 1, 2016 at 5:26:53 PM UTC-5, Bryce Glover wrote=
:<br class=3D"">
> expose the continuation-passing mechanisms upon which it will be built=
? I <br class=3D"">
> think that it might be useful for users to be able to build things on =
top <br class=3D"">
> of them.<br class=3D"">
<br class=3D"">
If you're talking about P0057 <<a href=3D"http://wg21.link/P0057" class=
=3D"">http://wg21.link/P0057</a>>-style coroutines, <br class=3D"">
not really. The idea of that coroutine proposal is to allow the <br class=
=3D"">
continuation of *the rest of your function*. That is, instead of passing a =
<br class=3D"">
function which will be continued by some process, you write your code as if=
<br class=3D"">
it were normal, non-continuation code. The `co_await` operator will <br cla=
ss=3D"">
transmit your current function's execution to whomever it is that will <br =
class=3D"">
"schedule" its continuation (depending on the value of the expression and a=
<br class=3D"">
*truly* dizzying array of customization points).<br class=3D"">
<br class=3D"">
But it's not something you could just shove a random function at and tell <=
br class=3D"">
it to continue it. Well, given how ludicrously customizable it is, you <br =
class=3D"">
could probably make it work that way. But that's not what it's *for*.<br cl=
ass=3D"">
</td></tr>
=20
<tr class=3D""><td style=3D"background-color: #FFFFFF; color:#2E2E2E;=
font-family: arial; padding:10px 15px; border:1px solid #d3d3d3;" class=3D=
"">
<span style=3D"color:#B1B0B0; font-size: 15px;" class=3D"">
Oliver Kowalke <<a href=3D"mailto:oliver.kowalke@gmail.com" cl=
ass=3D"">oliver.kowalke@gmail.com</a>>: Feb 02 08:47AM +0100
</span>
<br class=3D""><br class=3D"">
P099R0 (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pape=
rs/2015/p0099r0.pdf" class=3D"">http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2015/p0099r0.pdf</a>)<br class=3D"">
- allows to build coroutines, fibers and shift/reset operators on top of it=
<br class=3D"">
<br class=3D"">
</td></tr>
=20
<tr class=3D""><td style=3D"background-color: #FFFFFF; color:#2E2E2E;=
font-family: arial; padding:10px 15px; border:1px solid #d3d3d3;" class=3D=
"">
<span style=3D"color:#B1B0B0; font-size: 15px;" class=3D"">
Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com" class=3D""=
>jmckesson@gmail.com</a>>: Feb 02 07:30AM -0800
</span>
<br class=3D""><br class=3D"">
On Tuesday, February 2, 2016 at 2:47:36 AM UTC-5, Oliver Kowalke wr=
ote:<br class=3D"">
<br class=3D"">
> P099R0 (<br class=3D"">
> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p00=
99r0.pdf" class=3D"">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
5/p0099r0.pdf</a>) - <br class=3D"">
> allows to build coroutines, fibers and shift/reset operators on top of=
it<br class=3D"">
<br class=3D"">
I like P0099 (a lot), but I don't think it's a very good system for <br cla=
ss=3D"">
*continuation*-style APIs. The reason being the difficulty in doing the <br=
class=3D"">
continuation part.<br class=3D"">
<br class=3D"">
In order to continue the execution of a function (ie: what P0057's <br clas=
s=3D"">
`co_await` does), you have to do all of the following operations:<br class=
=3D"">
<br class=3D"">
1. Halt the current execution.<br class=3D"">
2. Transfer scheduling of the continuation to someone else.<br class=3D"">
3. Return control of the current thread to whomever it is that should get <=
br class=3D"">
it.<br class=3D"">
<br class=3D"">
In many cases, this is trivial with P0099. The case of generators, for <br =
class=3D"">
example, works fine. But it works fine because the code that schedules the =
<br class=3D"">
resumption of the function is also the code you are returning to. So it is =
<br class=3D"">
impossible for the coroutine to be resumed before you've transferred <br cl=
ass=3D"">
control elsewhere.<br class=3D"">
<br class=3D"">
P0057 is designed for cases where 2 and 3 are *different*. Where you're <br=
class=3D"">
firing off some potentially-asynchronous process that will execute <br clas=
s=3D"">
independently of the code that will receive the value.<br class=3D"">
<br class=3D"">
The issue that P0099 has with this is scenario is that, in order to make <b=
r class=3D"">
the potentially-asynchronous code work, you *must* do the items in the <br =
class=3D"">
order I outlined them above. That is, you need to halt the current <br clas=
s=3D"">
context's execution, such that after step 1, it is legal to continue its <b=
r class=3D"">
execution. You then need to transfer control to someone else who may <br cl=
ass=3D"">
asychronously resume that context's execution. That's why #1 has to happen =
<br class=3D"">
*first*; if #2 fires off a thread, you can't be sure that the thread won't =
<br class=3D"">
resume your function before you've finished with #3.<br class=3D"">
<br class=3D"">
In order to do that with P0099, you need a third execution context. One <br=
class=3D"">
that is not part of the call stack of the continuation itself. This means <=
br class=3D"">
that step 1 halts its own context and starts up the external one; this <br =
class=3D"">
means that the context is ready to be continued. And therefore, both steps =
<br class=3D"">
1 and 3 require a context switch. And while these are not an onerous <br cl=
ass=3D"">
burden, they aren't exactly *free* either. So it's not impossible to <br cl=
ass=3D"">
implement, but this style of programming has quite a bit of overhead. Also,=
<br class=3D"">
P0099 doesn't have any systems in place to help with this, so you'll have <=
br class=3D"">
to build this machinery yourself.<br class=3D"">
<br class=3D"">
I hope you're good at async programming, because it's *really* easy to get =
<br class=3D"">
wrong.<br class=3D"">
<br class=3D"">
By contrast, P0057 does things correctly by default. Of course it does; <br=
class=3D"">
P0057 is *all about* continuation-based programming. That's what it's for, =
<br class=3D"">
so it does it very well. P0099 is really designed for generalized stack <br=
class=3D"">
manipulation. So specialized use cases require specific fiddling and so <br=
class=3D"">
forth.<br class=3D"">
</td></tr>
=20
<tr class=3D""><td style=3D"background-color: #FFFFFF; color:#2E2E2E;=
font-family: arial; padding:10px 15px; border:1px solid #d3d3d3;" class=3D=
"">
<span style=3D"color:#B1B0B0; font-size: 15px;" class=3D"">
Oliver Kowalke <<a href=3D"mailto:oliver.kowalke@gmail.com" cl=
ass=3D"">oliver.kowalke@gmail.com</a>>: Feb 02 04:58PM +0100
</span>
<br class=3D""><br class=3D"">
> 2. Transfer scheduling of the continuation to someone else.<br=
class=3D"">
> 3. Return control of the current thread to whomever it is that should =
get<br class=3D"">
> it.<br class=3D"">
<br class=3D"">
P099R0 does not involve threads and or scheduler(s)<br class=3D"">
execution_context::operator() does suspend current context and resumes<br c=
lass=3D"">
context represented by the execution_context<br class=3D"">
<br class=3D"">
<br class=3D"">
> You then need to transfer control to someone else who may asychronousl=
y<br class=3D"">
> resume that context's execution.<br class=3D"">
<br class=3D"">
no, that's a false assumption - there is no 'someone else' the execution<br=
class=3D"">
control is transferred from context ctx1 to context ctx2<br class=3D"">
<br class=3D"">
<br class=3D"">
> That's why #1 has to happen *first*; if #2 fires off a thread,<br clas=
s=3D"">
<br class=3D"">
again, no threads are required<br class=3D"">
<br class=3D"">
<br class=3D"">
> In order to do that with P0099, you need a third execution context.<br=
class=3D"">
<br class=3D"">
not correct<br class=3D"">
<br class=3D"">
one benefit of P099R0 over P057 is, that it provides symmetric context<br c=
lass=3D"">
switch while P057 is only about asymmetric<br class=3D"">
symmetric: the next context is arbitrary<br class=3D"">
asymmetric: control must be transferred back to caller<br class=3D"">
</td></tr>
=20
</tbody></table>
<div style=3D"align:right; font-size:11px; margin-bottom: 40px; margin-to=
p:5px;" class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"x-msg://10/#dig=
est_top" class=3D"">Back to top</a>
</div>
=20
<a name=3D"group_thread_1" class=3D""></a>(snipped=E2=80=A6)</div>
<div style=3D"background-color: #f5f5f5;padding: 5px 20px;" class=3D"">
<table cellpadding=3D"0" cellspacing=3D"0" style=3D"width:100%" class=3D"=
">
<tbody class=3D""><tr class=3D"">
<td style=3D"padding-top:4px;font-family:arial,sans-serif;color:#636363=
;font-size:11px" class=3D"">
=20
You received this digest because you're subscribed to updates for thi=
s group. You can change your settings on the <a href=3D"https://groups.goog=
le.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!foru=
m/std-proposals/join" style=3D"color:#1155cc;text-decoration:none" class=3D=
"">group membership page</a>.<br class=3D"">
To unsubscribe from this group and stop receiving emails from it send=
an email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=
=3D"">std-proposals+unsubscribe@isocpp.org</a>.
</td>
</tr></tbody>
</table>
</div>
</div>
</div></blockquote></div><div class=3D""><br class=3D""></div><div class=3D=
""><blockquote type=3D"cite" class=3D""><div class=3D"">On Feb 3, 2016, at =
2:02 PM, <a href=3D"mailto:std-proposals@isocpp.org" class=3D"">std-proposa=
ls@isocpp.org</a> wrote:</div><br class=3D"Apple-interchange-newline"><div =
class=3D""><div class=3D"" style=3D"border: 1px solid rgb(211, 211, 211); m=
ax-width: 850px; font-family: Arial, sans-serif;"><div class=3D"" style=3D"=
background-color: rgb(245, 245, 245); padding: 10px 20px;"><table cellpaddi=
ng=3D"0" cellspacing=3D"0" class=3D"" style=3D"width: 810px;"><tbody class=
=3D""><tr class=3D""><td class=3D"" style=3D"width: 545px;"><span class=3D"=
" style=3D"font-size: 18px; line-height: 20px; font-family: arial; color: r=
gb(51, 51, 51);"><a href=3D"https://groups.google.com/a/isocpp.org/forum/?u=
tm_source=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics" clas=
s=3D"" style=3D"text-decoration: none; color: rgb(51, 51, 51);">std-proposa=
ls@isocpp.org</a></span></td><td class=3D"" style=3D"text-align: right; wid=
th: 233px;"><span class=3D"" style=3D"font-size: 20px; line-height: 24px; f=
ont-family: arial;"><a href=3D"https://groups.google.com/a/isocpp.org/forum=
/?utm_source=3Ddigest&utm_medium=3Demail/#!overview" target=3D"_blank" =
class=3D"" style=3D"color: rgb(221, 75, 57); text-decoration: none;">Google=
Groups</a></span></td><td class=3D"" style=3D"width: 32px;"><a href=3D"htt=
ps://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medi=
um=3Demail/#!overview" target=3D"_blank" class=3D""><img class=3D"" style=
=3D"border: 0px; vertical-align: middle;" apple-inline=3D"yes" id=3D"18380A=
5E-3BA4-4247-BFBD-CED1CA2FF1D1" height=3D"32" width=3D"32" apple-width=3D"y=
es" apple-height=3D"yes" src=3D"cid:3D532355-74B5-4A3C-8E5B-81002737D39B@hs=
d1.in.comcast.net."></a> </td>=
</tr></tbody></table></div><div class=3D"" style=3D"padding: 20px; backgrou=
nd-color: rgb(245, 245, 245);"><div class=3D"" style=3D"font-family: arial;=
color: rgb(34, 34, 34); padding: 0px;"><a name=3D"digest_top" class=3D"" s=
tyle=3D"font-size: 21px;">Topic digest </a><br class=3D""><span class=
=3D"" style=3D"font-size: 11px;"><a href=3D"https://groups.google.com/a/iso=
cpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#!forum/std-propos=
als/topics" class=3D"" style=3D"color: rgb(17, 85, 204); text-decoration: n=
one;">View all topics</a></span></div><div class=3D"" style=3D"font-size: 1=
3px; line-height: 18px; font-family: arial; color: rgb(34, 34, 34); padding=
: 0px; margin-bottom: 30px;"><ul class=3D"" style=3D"margin-left: 3px; padd=
ing-left: 0px;"><li class=3D""><a href=3D"x-msg://13/#group_thread_0" class=
=3D"" style=3D"color: rgb(17, 85, 204); text-decoration: none;">Continuatio=
ns for C++?</a> - <span class=3D"" style=3D"color: rgb(119, 119, =
119);">3 Updates</span></li><li class=3D"">(snipped=E2=80=A6)</li></ul></di=
v><a name=3D"group_thread_0" class=3D""></a><div class=3D"" style=3D"displa=
y: inline-block; font-family: arial; padding: 4px 0px 5px;"><a target=3D"_b=
lank" href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/t/e=
0c81dd2c5d4d5d4?utm_source=3Ddigest&utm_medium=3Demail" class=3D"" styl=
e=3D"font-size: 21px; color: rgb(17, 85, 204); text-decoration: none;">Cont=
inuations for C++? </a> </div><=
table class=3D"" style=3D"border-collapse: collapse; width: 809px;"><tbody =
class=3D""><tr class=3D""><td class=3D"" style=3D"background-color: rgb(255=
, 255, 255); color: rgb(46, 46, 46); font-family: arial; padding: 10px 15px=
; border: 1px solid rgb(211, 211, 211);"><span class=3D"" style=3D"color: r=
gb(177, 176, 176); font-size: 15px;">Giovanni Piero Deretta <<a href=3D"=
mailto:gpderetta@gmail.com" class=3D"">gpderetta@gmail.com</a>>: Feb 02 =
04:31PM -0800 </span><br class=3D""><br class=3D"">On Tuesday, Februar=
y 2, 2016 at 8:18:06 PM UTC, Nicol Bolas wrote:<br class=3D""> <br cla=
ss=3D"">> Well, I didn't think this was going to get so pedantic, or I w=
ould have <br class=3D"">> used terminology more carefully. That's =
my fault; *every* discussion of <br class=3D"">> coroutines ends in=
pedantry.<br class=3D""> <br class=3D"">amen!<br class=3D""><br class=
=3D""> <br class=3D"">> and one to the final destination.<br class=
=3D""> <br class=3D"">> You *cannot* do with just the initial and f=
inal contexts; you need that <br class=3D"">> third context in ther=
e that acts as an intermediary.<br class=3D""> <br class=3D"">FWIW, me=
and Oliver discussed this extensively a few months ago. As a <br clas=
s=3D"">recap, what I proposed is something like this:<br class=3D""><br cla=
ss=3D"">yield_with(ctx2, [](auto ctx) { SomeoneElse(move(ctx)); return ctx;=
});<br class=3D""> <br class=3D"">Only one context switch is needed. =
Yield_with can be implemented on top of <br class=3D"">P0099, but buil=
tin support would be better.<br class=3D""> <br class=3D""> <br c=
lass=3D"">>> asymmetric: control must be transferred back to caller<b=
r class=3D""> <br class=3D"">> Yes, but you're just proving my poin=
t. Symmetric coroutines are not <br class=3D"">> *continuations*.<b=
r class=3D""> <br class=3D"">They are actually.<br class=3D""><br clas=
s=3D""> <br class=3D""> <br class=3D"">> while(!test.IsFinishe=
d())<br class=3D"">> //Do some stuff.<br class=3D"">> }<br class=3D""=
> <br class=3D"">That's not really a proper first-class continuation. =
That's simulating a <br class=3D"">continuation by manual-rewriting wi=
th a lambda. It is like simulating a for <br class=3D"">loop with goto=
and if statements. Stackful coroutines (both symmetric and <br class=
=3D"">asymmetric) are in fact equivalent to first class one shot delimited&=
nbsp;<br class=3D"">continuation. <br class=3D""> <br class=3D"">=
-- gpd<br class=3D""></td></tr><tr class=3D""><td class=3D"" style=3D"backg=
round-color: rgb(255, 255, 255); color: rgb(46, 46, 46); font-family: arial=
; padding: 10px 15px; border: 1px solid rgb(211, 211, 211);"><span class=3D=
"" style=3D"color: rgb(177, 176, 176); font-size: 15px;">Oliver Kowalke <=
;<a href=3D"mailto:oliver.kowalke@gmail.com" class=3D"">oliver.kowalke@gmai=
l.com</a>>: Feb 03 08:55AM +0100 </span><br class=3D""><br class=3D=
""><br class=3D"">> BTW, I hope to see an updated P0099 revision or some=
thing similar for<br class=3D"">> Jacksonville.<br class=3D""> <br =
class=3D"">maybe<br class=3D""> <br class=3D""><snip><br class=
=3D"">see Giovanni's comment<br class=3D""> <br class=3D"">But because=
the OP asked "...useful for users to be able to build things on<br class=
=3D"">top of them..." - I believe that the mechanisms described in P099 are=
<br class=3D"">suitable to build high-level abstractions (as demonstrated i=
n some boost<br class=3D"">libraries).<br class=3D""></td></tr><tr class=3D=
""><td class=3D"" style=3D"background-color: rgb(255, 255, 255); color: rgb=
(46, 46, 46); font-family: arial; padding: 10px 15px; border: 1px solid rgb=
(211, 211, 211);"><span class=3D"" style=3D"color: rgb(177, 176, 176); font=
-size: 15px;">Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.com" class=
=3D"">jmckesson@gmail.com</a>>: Feb 03 10:56AM -0800 </span><br cla=
ss=3D""><br class=3D"">On Tuesday, February 2, 2016 at 7:31:57 PM UTC-5, Gi=
ovanni Piero Deretta <br class=3D"">wrote:<br class=3D""> <br cla=
ss=3D"">> yield_with(ctx2, [](auto ctx) { SomeoneElse(move(ctx)); return=
ctx; });<br class=3D""> <br class=3D"">> Only one context switch i=
s needed. Yield_with can be implemented on top of <br class=3D"">> =
P0099, but builtin support would be better.<br class=3D""> <br class=
=3D"">How exactly would `yield_with` be implemented on top of P0099?<br cla=
ss=3D""><br class=3D""> <br class=3D"">>> }<br class=3D""> =
<br class=3D"">> That's not really a proper first-class continuation. Th=
at's simulating a <br class=3D"">> continuation by manual-rewriting=
with a lambda.<br class=3D""> <br class=3D"">Well... yes. That was my=
point. With the language as is in C++14, that's <br class=3D"">the be=
st you can do.<br class=3D""> <br class=3D"">P0057 makes such construc=
ts more palatable and readable. P0099 improves <br class=3D"">things r=
elative to C++14, but it is still not as readable as P0057.<br class=3D"">&=
nbsp;<br class=3D"">I'd say my biggest concern with P0099 for continuations=
is that it's not <br class=3D"">clear exactly what the scope of the c=
ontinuation is, how far the <br class=3D"">asynchronous continuation p=
art can reach. P0057's scope is very well <br class=3D"">founded: that=
function. The immediate caller of the function is passed a <br class=
=3D"">return value that expresses the fact that the function will not neces=
sarily <br class=3D"">return the value immediately.<br class=3D"">&nbs=
p;<br class=3D"">For cases like generators, I find the scope limitation of =
P0057 to be... <br class=3D"">highly annoying. Using P0057 for generat=
ors is basically a gigantic hack on <br class=3D"">the feature. If you=
removed the ability to make generators from P0057, odds <br class=3D"=
">are good you'd reduce its complexity by 60+%.<br class=3D""> <br cla=
ss=3D"">However, for genuine continuation-style programming (which generato=
rs are <br class=3D"">not), I think the limitations of P0057's scope a=
re acceptable. While you <br class=3D"">can be sure that your current =
function is able to deal with <br class=3D"">possibly-asynchronous iss=
ues, you can't be sure that your immediate caller <br class=3D"">(and =
*their* immediate caller, all the way down to whomever started your <b=
r class=3D"">context) can handle them too.<br class=3D""> <br class=3D=
"">My concern is that with P0099, we'll be seeing a lot of this:<br class=
=3D""> <br class=3D"">future<int> MyContinueFunc(...)<br class=
=3D"">{<br class=3D"">//Context we return control to. IE: our caller.<br cl=
ass=3D"">execution_context ret_ctx =3D execution_context::current();<br cla=
ss=3D""> <br class=3D"">//Pointer to the new context we will create, w=
hich we use for our async <br class=3D"">call.<br class=3D"">auto func=
=3D [=3D](promise<int> prom, ...)<br class=3D"">{<br class=3D"">//Ac=
tual function that has continuations.<br class=3D"">yield_with(ret_ctx, [](=
auto ctx) { AsyncCall(move(ctx)); return ctx;})<br class=3D"">//After conti=
nuation<br class=3D"">prom.set(value);<br class=3D"">}<br class=3D""> =
<br class=3D"">promise<int> prom;<br class=3D"">future<int> ret=
=3D prom.get_future();<br class=3D"">execution_context ec(func, std::move(=
prom), ...);<br class=3D"">ec();<br class=3D"">return ret;<br class=3D"">}<=
br class=3D""> <br class=3D"">This is a huge amount of boilerplate for=
something that P0057 handles with <br class=3D"">minimal effort. Mayb=
e you can wrap all this boilerplate up into a <br class=3D"">(template=
) function call. But you would still have to write a function <br clas=
s=3D"">within a function:<br class=3D""> <br class=3D"">future<int&=
gt; MyContinueFunc()<br class=3D"">{<br class=3D"">//The promise is created=
internally, owned by the immediate caller to <br class=3D"">this func=
tion.<br class=3D"">//The promise type is the return type of the given func=
tion.<br class=3D"">//The return type of `context_continue` is a future con=
nected to the <br class=3D"">promise.<br class=3D"">return context_con=
tinue([](execution_context ret_ctx, ...)<br class=3D"">{<br class=3D"">//Ac=
tual function that has continuations.<br class=3D"">yield_with(ret_ctx, [](=
auto ctx) { AsyncCall(move(ctx)); return ctx;})<br class=3D"">//After conti=
nuation<br class=3D"">return value;<br class=3D"">};<br class=3D"">}<br cla=
ss=3D""> <br class=3D"">And the thing is, because P0099 is symmetric, =
it doesn't even really make <br class=3D"">this code more flexible by =
allowing multiple levels of stacks to continue <br class=3D"">with `yi=
eld_with`. Why? Because `ret_ctx` isn't available to code that the <br=
class=3D"">lambda calls, unless it explicitly passes it. In which case, th=
at code must <br class=3D"">be explicitly designed to yield to a parti=
cular location. So you can't <br class=3D"">transparently `yield_with`=
through functions that have no idea this sort of <br class=3D"">conti=
nuation is going on.<br class=3D""> <br class=3D"">Not without a globa=
l/thread_local variable of some kind that would hold <br class=3D"">`r=
et_ctx`'s value.<br class=3D""> <br class=3D"">It is like simulating a=
for loop with goto and if statements. Stackful <br class=3D"">> co=
routines (both symmetric and asymmetric) are in fact equivalent to first&nb=
sp;<br class=3D"">> class one shot delimited continuation.<br class=3D""=
> <br class=3D"">Equivalent in functionality, yes. But not in code nic=
eness, as shown above.<br class=3D""> <br class=3D"">P0099 is a good, =
low-level tool, and whether we get P0057 or not, we *need* <br class=
=3D"">P0099 or something very similar to it. But continuations are a higher=
-level <br class=3D"">tool. And having language support for continuati=
ons makes <br class=3D"">continuation-based code look a lot more reaso=
nable.<br class=3D""> <br class=3D"">I think of P0099 like function po=
inters, while P0057 is like virtual <br class=3D"">functions. The latt=
er is clearly higher-level than the former, and you need <br class=3D"=
">the former to implement the latter. But having support for the higher-lev=
el <br class=3D"">one makes the common use case much easier to use.<br=
class=3D""></td></tr></tbody></table><div class=3D"" style=3D"font-size: 1=
1px; margin-bottom: 40px; margin-top: 5px;"><a href=3D"x-msg://13/#digest_t=
op" class=3D"" style=3D"color: rgb(17, 85, 204); text-decoration: none;">Ba=
ck to top</a></div><a name=3D"group_thread_1" class=3D""></a>(snipped=E2=80=
=A6)</div><div class=3D"" style=3D"background-color: rgb(245, 245, 245); pa=
dding: 5px 20px;"><table cellpadding=3D"0" cellspacing=3D"0" class=3D"" sty=
le=3D"width: 810px;"><tbody class=3D""><tr class=3D""><td class=3D"" style=
=3D"padding-top: 4px; font-family: arial, sans-serif; color: rgb(99, 99, 99=
); font-size: 11px;">You received this digest because you're subscribed to =
updates for this group. You can change your settings on the <a href=3D=
"https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_=
medium=3Demail#!forum/std-proposals/join" class=3D"" style=3D"color: rgb(17=
, 85, 204); text-decoration: none;">group membership page</a>.<br class=3D"=
">To unsubscribe from this group and stop receiving emails from it send an =
email to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" class=
=3D"">std-proposals+unsubscribe@isocpp.org</a>.<br class=3D""><br class=3D"=
"></td></tr></tbody></table></div></div></div></blockquote></div><div class=
=3D""><br class=3D""></div><div class=3D"">@Nicol Bolas: </div><div c=
lass=3D""><br class=3D""></div><div class=3D""><blockquote type=3D"cite" cl=
ass=3D""><div class=3D"" style=3D"border: 1px solid rgb(211, 211, 211); max=
-width: 850px; font-family: Arial, sans-serif;"><div class=3D"" style=3D"pa=
dding: 20px; background-color: rgb(245, 245, 245);"><table class=3D"" style=
=3D"border-collapse: collapse; width: 809px;"><tbody class=3D""><tr class=
=3D""><td class=3D"" style=3D"background-color: rgb(255, 255, 255); color: =
rgb(46, 46, 46); font-family: arial; padding: 10px 15px; border: 1px solid =
rgb(211, 211, 211);">If you're talking about P0057 <<a href=3D"http://wg=
21.link/P0057" class=3D"">http://wg21.link/P0057</a>>-style coroutines,&=
nbsp;<br class=3D"">not really. The idea of that coroutine proposal is to a=
llow the <br class=3D"">continuation of *the rest of your function*. T=
hat is, instead of passing a <br class=3D"">function which will be con=
tinued by some process, you write your code as if <br class=3D"">it we=
re normal, non-continuation code. The `co_await` operator will <br cla=
ss=3D"">transmit your current function's execution to whomever it is that w=
ill <br class=3D"">"schedule" its continuation (depending on the value=
of the expression and a <br class=3D"">*truly* dizzying array of cust=
omization points).<br class=3D""> <br class=3D"">But it's not somethin=
g you could just shove a random function at and tell <br class=3D"">it=
to continue it. Well, given how ludicrously customizable it is, you <=
br class=3D"">could probably make it work that way. But that's not what it'=
s *for*.</td></tr></tbody></table></div></div></blockquote></div><br class=
=3D""><div class=3D"">OK, thanks for clarifying that! </div><div clas=
s=3D"">=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93</div><div class=3D"">@Oliver Kowalke: &nb=
sp;</div><div class=3D""><br class=3D""></div><div class=3D""><blockquote t=
ype=3D"cite" class=3D""><div class=3D"" style=3D"border: 1px solid rgb(211,=
211, 211); max-width: 850px; font-family: Arial, sans-serif;"><div class=
=3D"" style=3D"padding: 20px; background-color: rgb(245, 245, 245);"><table=
class=3D"" style=3D"border-collapse: collapse; width: 809px;"><tbody class=
=3D""><tr class=3D""><td class=3D"" style=3D"background-color: rgb(255, 255=
, 255); color: rgb(46, 46, 46); font-family: arial; padding: 10px 15px; bor=
der: 1px solid rgb(211, 211, 211);">P099R0 (<a href=3D"http://www.open-std.=
org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" class=3D"">http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf</a>)<br class=3D"">- a=
llows to build coroutines, fibers and shift/reset operators on top of it</t=
d></tr></tbody></table></div></div></blockquote><div class=3D""><br class=
=3D""></div></div><div class=3D"">Come to think of it, that=E2=80=99s actua=
lly probably more along the lines of what I was thinking about in the first=
place. </div><div class=3D"">=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=
=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=
=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=
=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93=E2=80=93</div><div clas=
s=3D"">@Nicol Bolas, @Oliver Kowalke, @Giovanni Piero Deretta: </div>=
<div class=3D""><br class=3D""></div><div class=3D"">All of these points th=
at you=E2=80=99ve all raised are very insightful. I look forward to s=
eeing progress in this area! </div><div class=3D""><br class=3D"webki=
t-block-placeholder"></div><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div class=3D"">=E2=80=94=E2=80=89Bry=
ce Glover</div><div class=3D"">=E3=80=80=E2=80=89<a href=3D"mailto:RandomDS=
devel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div>
</div>
<br class=3D""></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
--Apple-Mail=_A840FC09-E6DA-40FD-96CC-B0D792FE79BC
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename=groups-32.png
Content-Type: image/png;
name="groups-32.png"
Content-Id: <3D532355-74B5-4A3C-8E5B-81002737D39B@hsd1.in.comcast.net.>
iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAMAAABEpIrGAAACH1BMVEX///8AAADx7+Tz8ejn5NXY
1sihoZgvdu4udu7l4tOsq6AtdOzLybuwr6Qsc+sscurj4NDj4NArcuoqcenj4NDj4NAqcOgpb+cw
ePD39/c3f/Q2fvQ8hPehw/82fvM9hvjs6tw9hPfx7+Sfn5bt6t3v7eJEjfvw7uM4gPWixP/p5tnp
59mgoJfq6Nro5dfy8OVDi/o7g/bn5NUxefAxevEvd+8ze/Kjxf80fPNBivo9hffk4dE+hvg6gvY4
gfU1ffM5gfY3fvRAiPkzfPI/iPlAifk0fPLt697v7OHj4NA9hfhFjfvd2svy9PhHj/zf3M3r6dvZ
18jh3s8rcuqQuf6gw//a2Mnu699Bifqnx//b2cpEi/vq6ds5gvbe3MxBifmdnZTd28zg3c7l4tLc
2crg3s5FjvyioZnu697o5dihoJiMtv0udu7x7+Xm49Ti38/w7uJCi/qfnpUye/LMyr04f/Xo5dYt
dOwyevHs6dwye/GhoZihxP85gfU+h/gvdu7u7OCavvdDi/tCivrNy77q59mgoJiWvf7y8efm49Oe
nZSSuv2IlaU2euqXu/Y0ffMsc+vl4tPq59pGj/yenpWdnpWPmKBEft5pn/Y/h/mko5qko5mjopmi
opkwefAtde0ude0scuqlpJukpJpkm/OPuP1EjPuYvPa80va60faRuf4qcekwd++YvPfy8eby8OYq
cOiNt/1IkP2Mtfw4f/TfRnhPAAAAGHRSTlMAABCAgICfEK+AgI/vYGDv7zAw788QEM9qSN7YAAAC
IklEQVR4Xr3PU7NcQRiG0ewT2tge27Z9bNu2Hdu2bfzAfD3TU5k5t6nKe/usamz6LyM2nzeMiBXj
suR6f0IqXGjWadT6WbN59MLODCj4+g33OtTLdWfUA3rUb3RhYDD8LO2VnzzVFva6WVOL/3eIv2Zf
tD7t8uArRsSlt4rkRlcsikDQT4d4JwKeLBAreovkTRP14VWBiPUBYDYAxbj8bdOEqy3qFbCsb0VJ
M4G4fd5KelIYjMuMRujhVa/7BEW9U9J8IIJAKgtkSZerHvXCQgqWfsKU1fIXJNdjsfAD6CIRAugG
9AQyNYbBel0U8kdHNWv6QlFXaf7H8hDcQI5lQX/C6xUIHA6Hybfin6EZZnmZs1gAVGKQkLrdIrba
8SbTeecQ9wsOICt7MJAKWZY1+Xwt999TsA+v4QVwgK2nEwPhAtRzDlVDCZVeCcdxlwB0lmGwUB4M
BlUqVQOFx3E1NaTNVtaKQbPO71cqZ2g6BPfH7VPz8EXys22ttQODmxoahnLAGYGOHgAHDHcUY6BR
hxiG4SHn9rXh4m4M1AMQocYhL8L5uD/vbsRAP4tixJ7OVjLb5xprMZg1nx4cPKuVSCSTkxfb2y9f
Sfdnc7UVGGwxj0739S0tLWm1QG7fuXsv3a9XbMUAbfrho8dPthGZbd+B+guCyAGe6ZevdkHD2w29
Kh949uwlcrZvf9WnfHDgIJG3Q4e/54EjR4kNO3Ycg3/dHzCRrKSF+gKYAAAAAElFTkSuQmCC
--Apple-Mail=_A840FC09-E6DA-40FD-96CC-B0D792FE79BC--
--Apple-Mail=_1414930B-8112-45E6-B0DD-4ACF0D5560AB--
.