Topic: Where'd P0099R0's `std::execution_context::current()`
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Mon, 28 Nov 2016 18:34:56 -0500
Raw View
--Apple-Mail=_8C316386-7705-4AF2-A896-C6BC71B35998
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
I noticed that the =E2=80=98Revision History=E2=80=99 section of P0099=
R1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf> me=
ntions that the static `current()` member function present in P0099R0 <http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=80=99s =
version of the class `std::execution_context` which both versions of the pr=
oposal present for possible addition to the C++ standard was removed in P00=
99R1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>=
=E2=80=99s version of it. This, however, strikes me as quite puzzling, as =
I found that `std::execution_context`=E2=80=99s API was much more understan=
dable with that static member function included than without it. This is b=
ecause I find it somewhat easier to keep track of an `std::execution_contex=
t` when I can see exactly where it was explicitly created than when the com=
piler generates it at a point in a program=E2=80=99s execution that some, m=
yself included, might find hard to pin down. I know that one isn=E2=80=99t=
supposed to see and/or use `std::execution_context` all that often, but I =
also don=E2=80=99t see any benefits to this rather baffling API change besi=
de the fact that it makes the class even more of a niche tool than it alrea=
dy is. What, then, was the original motivation for removing P0099R0 <http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=80=99s `=
std::execution_context::current()` from P0099R1 <http://www.open-std.org/jt=
c1/sc22/wg21/docs/papers/2016/p0099r1.pdf>? Might it have had something to=
do with any of the other API changes mentioned in the latter=E2=80=99s =E2=
=80=98Revision History=E2=80=99 section? =20
Highly curious,=20
Bryce Glover
RandomDSdevel@gmail.com
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/17E286BF-AA21-4F6B-BE0D-427A26569144%40gmail.com=
..
--Apple-Mail=_8C316386-7705-4AF2-A896-C6BC71B35998
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; I noticed that the =E2=80=98Revision History=E2=80=99 sec=
tion of <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2016/p0099r1.pdf" class=3D"">P0099R1</a> mentions that the static `cur=
rent()` member function present in <a href=3D"http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" class=3D"">P0099R0</a>=E2=80=
=99s version of the class `std::execution_context` which both versions of t=
he proposal present for possible addition to the C++ standard was removed i=
n <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p=
0099r1.pdf" class=3D"">P0099R1</a>=E2=80=99s version of it. This, how=
ever, strikes me as quite puzzling, as I found that `std::execution_context=
`=E2=80=99s API was <i class=3D"">much</i> more understandable <i clas=
s=3D"">with</i> that static member function included than without it. =
This is because I find it somewhat easier to keep track of an `std::e=
xecution_context` when I can see exactly where it was explicitly created th=
an when the compiler generates it at a point in a program=E2=80=99s executi=
on that some, myself included, might find hard to pin down. I know th=
at one isn=E2=80=99t supposed to see and/or use `std::execution_context` al=
l that often, but I <i class=3D"">also</i> don=E2=80=99t see any benef=
its to this rather baffling API change beside the fact that it makes the cl=
ass even <i class=3D"">more</i> of a niche tool than it already is. &n=
bsp;What, then, was the original motivation for removing <a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" class=3D=
"">P0099R0</a>=E2=80=99s `std::execution_context::current()` from <a h=
ref=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf"=
class=3D"">P0099R1</a>? Might it have had something to do with any o=
f the <i class=3D"">other</i> API changes mentioned in the latter=E2=
=80=99s =E2=80=98Revision History=E2=80=99 section? </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 style=3D"color: rgb(0, 0, 0); le=
tter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Hi=
ghly curious, </div><div class=3D""> Bryce Glover</=
div><div class=3D""> <a href=3D"mailto:RandomDSdevel@gma=
il.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div></div>
</div>
</body></html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/17E286BF-AA21-4F6B-BE0D-427A26569144%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/17E286BF-AA21-4F6B-BE0D-427A26569144%=
40gmail.com</a>.<br />
--Apple-Mail=_8C316386-7705-4AF2-A896-C6BC71B35998--
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Mon, 28 Nov 2016 18:40:14 -0500
Raw View
--Apple-Mail=_41C6EC87-2C67-44D3-B2BD-D8C5A420BFDB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On Nov 28, 2016, at 6:34 PM, Bryce Glover <randomdsdevel@gmail.com> wrote=
:
>=20
> I noticed that the =E2=80=98Revision History=E2=80=99 section of P00=
99R1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf> =
mentions that the static `current()` member function present in P0099R0 <ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=80=99=
s version of the class `std::execution_context` which both versions of the =
proposal present for possible addition to the C++ standard was removed in P=
0099R1 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf=
>=E2=80=99s version of it. This, however, strikes me as quite puzzling, as=
I found that `std::execution_context`=E2=80=99s API was much more understa=
ndable with that static member function included than without it. This is =
because I find it somewhat easier to keep track of an `std::execution_conte=
xt` when I can see exactly where it was explicitly created than when the co=
mpiler generates it at a point in a program=E2=80=99s execution that some, =
myself included, might find hard to pin down. I know that one isn=E2=80=99=
t supposed to see and/or use `std::execution_context` all that often, but I=
also don=E2=80=99t see any benefits to this rather baffling API change bes=
ide the fact that it makes the class even more of a niche tool than it alre=
ady is. What, then, was the original motivation for removing P0099R0 <http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=80=99s =
`std::execution_context::current()` from P0099R1 <http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>? Might it have had something t=
o do with any of the other API changes mentioned in the latter=E2=80=99s =
=E2=80=98Revision History=E2=80=99 section? =20
>=20
> Highly curious,=20
> Bryce Glover
> RandomDSdevel@gmail.com <mailto:RandomDSdevel@gmail.com>
Hold on just a little while; P0444R0 <http://www.open-std.org/jtc1/sc2=
2/wg21/docs/papers/2016/p0444r0.pdf>, which I am currently perusing, might =
have an answer to this question in its =E2=80=98Apology=E2=80=99 section an=
d/or elsewhere. Is that document supposed to answer the question I origina=
lly posed, or would the answer to my initial head-scratch be something else=
=E2=80=A6? =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/63D05C85-46E1-42B5-B263-77FA20B0C024%40gmail.com=
..
--Apple-Mail=_41C6EC87-2C67-44D3-B2BD-D8C5A420BFDB
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 Nov 28, 2016, at 6:34 PM, Bryce =
Glover <<a href=3D"mailto:randomdsdevel@gmail.com" class=3D"">randomdsde=
vel@gmail.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><=
div class=3D""><meta http-equiv=3D"Content-Type" content=3D"text/html chars=
et=3Dutf-8" class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space;" class=3D""><div class=3D=
""> I noticed that the =E2=80=98Revision History=E2=80=
=99 section of <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2016/p0099r1.pdf" class=3D"">P0099R1</a> mentions that the stat=
ic `current()` member function present in <a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" class=3D"">P0099R0</a>=
=E2=80=99s version of the class `std::execution_context` which both version=
s of the proposal present for possible addition to the C++ standard was rem=
oved in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/=
2016/p0099r1.pdf" class=3D"">P0099R1</a>=E2=80=99s version of it. Thi=
s, however, strikes me as quite puzzling, as I found that `std::execution_c=
ontext`=E2=80=99s API was <i class=3D"">much</i> more understandable <=
i class=3D"">with</i> that static member function included than withou=
t it. This is because I find it somewhat easier to keep track of an `=
std::execution_context` when I can see exactly where it was explicitly crea=
ted than when the compiler generates it at a point in a program=E2=80=99s e=
xecution that some, myself included, might find hard to pin down. I k=
now that one isn=E2=80=99t supposed to see and/or use `std::execution_conte=
xt` all that often, but I <i class=3D"">also</i> don=E2=80=99t see any=
benefits to this rather baffling API change beside the fact that it makes =
the class even <i class=3D"">more</i> of a niche tool than it already =
is. What, then, was the original motivation for removing <a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" cl=
ass=3D"">P0099R0</a>=E2=80=99s `std::execution_context::current()` from&nbs=
p;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r=
1.pdf" class=3D"">P0099R1</a>? Might it have had something to do with=
any of the <i class=3D"">other</i> API changes mentioned in the latte=
r=E2=80=99s =E2=80=98Revision History=E2=80=99 section? </div><br cla=
ss=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=
style=3D"letter-spacing: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-=
nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D""><div c=
lass=3D"">Highly curious, </div><div class=3D""> Br=
yce Glover</div><div class=3D""> <a href=3D"mailto:Rando=
mDSdevel@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div=
></div>
</div>
</div></div></blockquote></div><br class=3D""><div class=3D""> =
Hold on just a little while; <a href=3D"http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2016/p0444r0.pdf" class=3D"">P0444R0</a>, which=
I am currently perusing, might have an answer to this question in its =E2=
=80=98Apology=E2=80=99 section and/or elsewhere. Is that document sup=
posed to answer the question I originally posed, or would the answer to my =
initial head-scratch be something else=E2=80=A6? </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></body></html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/63D05C85-46E1-42B5-B263-77FA20B0C024%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/63D05C85-46E1-42B5-B263-77FA20B0C024%=
40gmail.com</a>.<br />
--Apple-Mail=_41C6EC87-2C67-44D3-B2BD-D8C5A420BFDB--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 28 Nov 2016 18:01:49 -0800 (PST)
Raw View
------=_Part_12083_1417130137.1480384909936
Content-Type: multipart/alternative;
boundary="----=_Part_12084_34672564.1480384909937"
------=_Part_12084_34672564.1480384909937
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, November 28, 2016 at 6:40:18 PM UTC-5, Bryce Glover wrote:
>
> On Nov 28, 2016, at 6:34 PM, Bryce Glover <random...@gmail.com=20
> <javascript:>> wrote:
>
> I noticed that the =E2=80=98Revision History=E2=80=99 section of P00=
99R1=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf> men=
tions=20
> that the static `current()` member function present in P0099R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=
=80=99s=20
> version of the class `std::execution_context` which both versions of the=
=20
> proposal present for possible addition to the C++ standard was removed in=
=20
> P0099R1=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>=E2=
=80=99s=20
> version of it. This, however, strikes me as quite puzzling, as I found=
=20
> that `std::execution_context`=E2=80=99s API was *much* more understandabl=
e *with* that=20
> static member function included than without it. This is because I find =
it=20
> somewhat easier to keep track of an `std::execution_context` when I can s=
ee=20
> exactly where it was explicitly created than when the compiler generates =
it=20
> at a point in a program=E2=80=99s execution that some, myself included, m=
ight find=20
> hard to pin down. I know that one isn=E2=80=99t supposed to see and/or u=
se=20
> `std::execution_context` all that often, but I *also* don=E2=80=99t see a=
ny=20
> benefits to this rather baffling API change beside the fact that it makes=
=20
> the class even *more* of a niche tool than it already is. What, then,=20
> was the original motivation for removing P0099R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=
=80=99s=20
> `std::execution_context::current()` from P0099R1=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>?=20
> Might it have had something to do with any of the *other* API changes=20
> mentioned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 sect=
ion? =20
>
>
The reason is effectively stated in the proposal, but more detail is=20
provided in the Boost.Context documentation=20
<http://www.boost.org/doc/libs/1_62_0/libs/context/doc/html/context/ecv2.ht=
ml>.=20
That project mirrors this proposal (in that Boost.Context's writer is the=
=20
one who wrote the P0099 proposals).
In R0, `execution_context` was internally reference counted. That's what=20
made `current` possible; you could always return an object that stored=20
another reference to your current execution context. Also, `current` has to=
=20
actually store the current context in some form of variable accessible from=
=20
within that context.
But that requires that the internal construct behind `execution_context`=20
was heap-allocated and reference counted. If you don't need that=20
functionality, then it is a performance/resource burden that you cannot=20
avoid.
Thus, R1 and the current Boost.Context removes this notion.=20
`execution_context` becomes a move-only type. If you want it reference=20
counted, then you write a wrapper that does that. If you want `current`,=20
then your wrapper will need to make sure that the current context variable=
=20
is set when resuming the context.
Basically, `execution_context` is a *much* lower-level construct now.
>
> Highly curious,=20
> Bryce Glover
> Random...@gmail.com <javascript:>
>
>
> Hold on just a little while; P0444R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0444r0.pdf>,=20
> which I am currently perusing, might have an answer to this question in i=
ts=20
> =E2=80=98Apology=E2=80=99 section and/or elsewhere. Is that document sup=
posed to answer=20
> the question I originally posed, or would the answer to my initial=20
> head-scratch be something else=E2=80=A6?=20
>
Not really. P0444 is more a thought experiment; by the authors' own=20
admission, they don't have the resources and ability to implement anything=
=20
they're talking about. It doesn't present a fully fleshed out proposal, not=
=20
to the point of explicit API calls.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fa3eb676-0d16-4fe4-bfc0-c8a1a4a2700a%40isocpp.or=
g.
------=_Part_12084_34672564.1480384909937
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, November 28, 2016 at 6:40:18 PM UTC-5, =
Bryce Glover wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=
=3D"word-wrap:break-word"><div><blockquote type=3D"cite"><div>On Nov 28, 20=
16, at 6:34 PM, Bryce Glover <<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"zx2DhBoABQAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">random...@gmail.com</a>> wrote:</div><br><di=
v><div style=3D"word-wrap:break-word"><div>=C2=A0 =C2=A0 =C2=A0I noticed th=
at the =E2=80=98Revision History=E2=80=99 section of=C2=A0<a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpape=
rs%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckY=
xmTsvtAzKCZ2PhAVg';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
nnneVgKckYxmTsvtAzKCZ2PhAVg';return true;">P0099R1</a>=C2=A0mentions th=
at the static `current()` member function present in=C2=A0<a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpape=
rs%2F2015%2Fp0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbK=
Jkd0frHuXT9kPA1dA';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2015%2Fp0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
oRShmb9IbKJkd0frHuXT9kPA1dA';return true;">P0099R0</a>=E2=80=99s versio=
n of the class `std::execution_context` which both versions of the proposal=
present for possible addition to the C++ standard was removed in=C2=A0<a h=
ref=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf"=
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://=
www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%=
2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true;" onclick=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true;">P0099R1</a>=E2=
=80=99s version of it. =C2=A0This, however, strikes me as quite puzzling, a=
s I found that `std::execution_context`=E2=80=99s API was <i>much</i>=C2=A0=
more understandable <i>with</i>=C2=A0that static member function included t=
han without it. =C2=A0This is because I find it somewhat easier to keep tra=
ck of an `std::execution_context` when I can see exactly where it was expli=
citly created than when the compiler generates it at a point in a program=
=E2=80=99s execution that some, myself included, might find hard to pin dow=
n. =C2=A0I know that one isn=E2=80=99t supposed to see and/or use `std::exe=
cution_context` all that often, but I <i>also</i>=C2=A0don=E2=80=99t see an=
y benefits to this rather baffling API change beside the fact that it makes=
the class even <i>more</i>=C2=A0of a niche tool than it already is. =C2=A0=
What, then, was the original motivation for removing=C2=A0<a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.co=
m/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpape=
rs%2F2015%2Fp0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbK=
Jkd0frHuXT9kPA1dA';return true;" onclick=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2015%2Fp0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
oRShmb9IbKJkd0frHuXT9kPA1dA';return true;">P0099R0</a>=E2=80=99s `std::=
execution_context::<wbr>current()` from=C2=A0<a href=3D"http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dht=
tp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp=
0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2P=
hAVg';return true;" onclick=3D"this.href=3D'http://www.google.com/u=
rl?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmT=
svtAzKCZ2PhAVg';return true;">P0099R1</a>? =C2=A0Might it have had some=
thing to do with any of the <i>other</i>=C2=A0API changes mentioned in the =
latter=E2=80=99s =E2=80=98Revision History=E2=80=99 section? =C2=A0</div></=
div></div></blockquote></div></div></blockquote><div><br>The reason is effe=
ctively stated in the proposal, but <a href=3D"http://www.boost.org/doc/lib=
s/1_62_0/libs/context/doc/html/context/ecv2.html">more detail is provided i=
n the Boost.Context documentation</a>. That project mirrors this proposal (=
in that Boost.Context's writer is the one who wrote the P0099 proposals=
).<br><br>In R0, `execution_context` was internally reference counted. That=
's what made `current` possible; you could always return an object that=
stored another reference to your current execution context. Also, `current=
` has to actually store the current context in some form of variable access=
ible from within that context.<br><br>But that requires that the internal c=
onstruct behind `execution_context` was heap-allocated and reference counte=
d. If you don't need that functionality, then it is a performance/resou=
rce burden that you cannot avoid.<br><br>Thus, R1 and the current Boost.Con=
text removes this notion. `execution_context` becomes a move-only type. If =
you want it reference counted, then you write a wrapper that does that. If =
you want `current`, then your wrapper will need to make sure that the curre=
nt context variable is set when resuming the context.<br><br>Basically, `ex=
ecution_context` is a <i>much</i> lower-level construct now.<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-word"=
><div><blockquote type=3D"cite"><div><div style=3D"word-wrap:break-word"><b=
r><div>
<div style=3D"letter-spacing:normal;text-align:start;text-indent:0px;text-t=
ransform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><di=
v style=3D"letter-spacing:normal;text-align:start;text-indent:0px;text-tran=
sform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div s=
tyle=3D"letter-spacing:normal;text-align:start;text-indent:0px;text-transfo=
rm:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><div>High=
ly curious,=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0Bryce Glover</div><div>=C2=
=A0 =C2=A0 =C2=A0<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"zx2DhBoABQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
turn true;">Random...@gmail.com</a></div></div></div></div>
</div>
</div></div></blockquote></div><br><div>=C2=A0 =C2=A0 =C2=A0Hold on just a =
little while;=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2016/p0444r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.or=
g%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0444r0.pdf\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNFuzDcALy1N5eLoNdlSU6gJYIGHEQ';return true;" on=
click=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.o=
pen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0444r0.pdf\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFuzDcALy1N5eLoNdlSU6gJYIGHEQ';return=
true;">P0444R0</a>, which I am currently perusing, might have an answer to=
this question in its =E2=80=98Apology=E2=80=99 section and/or elsewhere. =
=C2=A0Is that document supposed to answer the question I originally posed, =
or would the answer to my initial head-scratch be something else=E2=80=A6? =
<br></div></div></blockquote><div><br>Not really. P0444 is more a thought e=
xperiment; by the authors' own admission, they don't have the resou=
rces and ability to implement anything they're talking about. It doesn&=
#39;t present a fully fleshed out proposal, not to the point of explicit AP=
I calls.</div><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fa3eb676-0d16-4fe4-bfc0-c8a1a4a2700a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fa3eb676-0d16-4fe4-bfc0-c8a1a4a2700a=
%40isocpp.org</a>.<br />
------=_Part_12084_34672564.1480384909937--
------=_Part_12083_1417130137.1480384909936--
.
Author: Oliver Kowalke <oliver.kowalke@gmail.com>
Date: Tue, 29 Nov 2016 10:26:43 +0100
Raw View
--001a11448a32fb9eac05426d3079
Content-Type: text/plain; charset=UTF-8
2016-11-29 3:01 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
>
> The reason is effectively stated in the proposal, but more detail is
> provided in the Boost.Context documentation
> <http://www.boost.org/doc/libs/1_62_0/libs/context/doc/html/context/ecv2.html>.
> That project mirrors this proposal (in that Boost.Context's writer is the
> one who wrote the P0099 proposals).
>
(the proposal mirrors the project)
the implementation of R1 in boost.context simply stores the stack pointer
inside of execution_context. if a context is suspended, relevant registers
are pushed onto the stack and a new instance of execution_context (holding
the stack pointer) is forwarded to the resumed context.
if a context is resumed the internal pointer of execution_context gets
assigned to the stack pointer, the content of the relevant registers is
popped from the stack and the context gets executed.
in other words, stack pointers are forwarded between different instances of
execution_context.
implementation of R1 shows a better performance than R0 (maybe better to
omptimizable by the compiler; no ref-couting)
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19H6yNmXpGYXE4xa3o9BRpCK7SCYrMLxWFifuw_JXEgqA%40mail.gmail.com.
--001a11448a32fb9eac05426d3079
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=
-11-29 3:01 GMT+01:00 Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank"><span tabindex=3D"-1" id=3D":1la.10" =
style=3D"" class=3D"">jmckesson</span>@gmail.com</a>></span>:<br><blockq=
uote 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""></span><div><br>T=
he reason is effectively stated in the proposal, but <a href=3D"http://www.=
boost.org/doc/libs/1_62_0/libs/context/doc/html/context/ecv2.html" target=
=3D"_blank">more detail is provided in the Boost.Context documentation</a>.=
That project mirrors this proposal (in that Boost.Context's writer is =
the one who wrote the P0099 proposals).<br></div></div></blockquote><div><b=
r></div><div>(the proposal mirrors the project)<br><br></div><div>the imple=
mentation of R1 in boost.context simply stores the stack pointer inside of =
execution_context. if a context is suspended, relevant registers are pushed=
onto the stack and a new instance of execution_context (holding the stack =
pointer) is forwarded to the resumed context.<br></div><div>if a context is=
resumed the internal pointer of execution_context gets assigned to the sta=
ck pointer, the content of the relevant registers is popped from the stack =
and the context gets executed.<br></div><div>in other words, stack pointers=
are forwarded between different instances of execution_context.<br><br></d=
iv><div>implementation of R1 shows a better performance than R0 (maybe bett=
er to <span tabindex=3D"-1" id=3D":1la.11" style=3D"" class=3D"">omptimizab=
le</span> by the compiler; no ref-<span tabindex=3D"-1" id=3D":1la.12" styl=
e=3D"" class=3D"">couting</span>)<br></div></div><br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19H6yNmXpGYXE4xa3o9BRpCK7SCYr=
MLxWFifuw_JXEgqA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19H6yNm=
XpGYXE4xa3o9BRpCK7SCYrMLxWFifuw_JXEgqA%40mail.gmail.com</a>.<br />
--001a11448a32fb9eac05426d3079--
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Tue, 29 Nov 2016 20:14:41 -0500
Raw View
--Apple-Mail=_6E6C0B16-B680-4417-8251-F2F7192F3C43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
> On Nov 29, 2016, at 5:14 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 <>
> View all topics <https://groups.google.com/a/isocpp.org/forum/?utm_source=
=3Ddigest&utm_medium=3Demail#!forum/std-proposals/topics>
> (snipped=E2=80=A6)
> Where'd P0099R0's `std::execution_context::current()` Function Go In P009=
9R1 and Why? <x-msg://4/#group_thread_1> - 4 Updates
> (snipped=E2=80=A6)
> <>Where'd P0099R0's `std::execution_context::current()` Function Go In P=
0099R1 and Why? <http://groups.google.com/a/isocpp.org/group/std-proposals/=
t/e1f882f8006af642?utm_source=3Ddigest&utm_medium=3Demail> =20
> (snipped=E2=80=A6)
> Nicol Bolas <jmckesson@gmail.com>: Nov 28 06:01PM -0800=20
>=20
> On Monday, November 28, 2016 at 6:40:18 PM UTC-5, Bryce Glover wrote:
> > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf <h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>>?=20
> > Might it have had something to do with any of the *other* API changes=
=20
> > mentioned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 se=
ction?=20
> =20
> The reason is effectively stated in the proposal, but more detail is=20
> provided in the Boost.Context documentation=20
> <http://www.boost.org/doc/libs/1_62_0/libs/context/doc/html/context/ecv2.=
html <http://www.boost.org/doc/libs/1_62_0/libs/context/doc/html/context/ec=
v2.html>>.=20
> That project mirrors this proposal (in that Boost.Context's writer is the=
=20
> one who wrote the P0099 proposals).
> =20
> In R0, `execution_context` was internally reference counted. That's what=
=20
> made `current` possible; you could always return an object that stored=20
> another reference to your current execution context. Also, `current` has =
to=20
> actually store the current context in some form of variable accessible fr=
om=20
> within that context.
> =20
> But that requires that the internal construct behind `execution_context`=
=20
> was heap-allocated and reference counted. If you don't need that=20
> functionality, then it is a performance/resource burden that you cannot=
=20
> avoid.
> =20
> Thus, R1 and the current Boost.Context removes this notion.=20
> `execution_context` becomes a move-only type. If you want it reference=20
> counted, then you write a wrapper that does that. If you want `current`,=
=20
> then your wrapper will need to make sure that the current context variabl=
e=20
> is set when resuming the context.
> =20
> Basically, `execution_context` is a *much* lower-level construct now.
> =20
> > =E2=80=98Apology=E2=80=99 section and/or elsewhere. Is that document su=
pposed to answer=20
> > the question I originally posed, or would the answer to my initial=20
> > head-scratch be something else=E2=80=A6?=20
> =20
> Not really. P0444 is more a thought experiment; by the authors' own=20
> admission, they don't have the resources and ability to implement anythin=
g=20
> they're talking about. It doesn't present a fully fleshed out proposal, n=
ot=20
> to the point of explicit API calls.
> Oliver Kowalke <oliver.kowalke@gmail.com>: Nov 29 10:26AM +0100=20
>=20
> > <http://www.boost.org/doc/libs/1_62_0/libs/context/doc/html/context/ecv=
2.html <http://www.boost.org/doc/libs/1_62_0/libs/context/doc/html/context/=
ecv2.html>>.
> > That project mirrors this proposal (in that Boost.Context's writer is t=
he
> > one who wrote the P0099 proposals).
> =20
> (the proposal mirrors the project)
> =20
> the implementation of R1 in boost.context simply stores the stack pointer
> inside of execution_context. if a context is suspended, relevant register=
s
> are pushed onto the stack and a new instance of execution_context (holdin=
g
> the stack pointer) is forwarded to the resumed context.
> if a context is resumed the internal pointer of execution_context gets
> assigned to the stack pointer, the content of the relevant registers is
> popped from the stack and the context gets executed.
> in other words, stack pointers are forwarded between different instances =
of
> execution_context.
> =20
> implementation of R1 shows a better performance than R0 (maybe better to
> omptimizable by the compiler; no ref-couting)
> Back to top <x-msg://4/#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>.
Ah, that makes sense=E2=80=89=E2=80=94=E2=80=89and, now that you menti=
on it, Nicol, I found where the explanation both you and Oliver gave is ref=
erenced in P0099R1: it=E2=80=99s buried at the bottom of page 5 in a footn=
ote, so no wonder I forgot about it, silly me! And, yes, I agree I was jus=
t grasping for straws when I tried looking in related papers for what was, =
it turns out, so obviously right under my nose the entire time. In any cas=
e, thank you both for your helpful clarification, and I look forward to see=
ing where all of this leads. =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
P. S.: Has a reference-counted wrapper for the current (confusion and/or p=
un not intended) version of `execution_context` as presented in P0099R1 and=
implemented in Boost.Context also been proposed for standardization yet, b=
y any chance, or are users expected to write their own instances of such a =
wrapper class all by themselves? =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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1F2AD4FB-F0D1-4744-9FA1-2B0EBA0A4A0D%40gmail.com=
..
--Apple-Mail=_6E6C0B16-B680-4417-8251-F2F7192F3C43
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 Nov 29, 2016, at 5:14 PM, <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"">(snipped=E2=80=A6)</li>
=20
<li class=3D"">
<a style=3D"color:#1155cc;text-decoration:none" href=3D"x-msg://4/#gr=
oup_thread_1" class=3D"">
Where'd P0099R0's `std::execution_context::current()` Function Go In =
P0099R1 and Why?</a> -
<span style=3D"color:#777777" class=3D"">4 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-bl=
ock; font-family: arial; padding: 4px 0 5px 0px;" class=3D""><a target=3D"_=
blank" href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/t/=
e1f882f8006af642?utm_source=3Ddigest&utm_medium=3Demail" style=3D"font-=
size:21px; color:#1155CC; text-decoration:none" class=3D"">Where'd P0099R0'=
s `std::execution_context::current()` Function Go In P0099R1 and Why?
</a>
=20
</div>
<table style=3D"border-collapse: collapse; width: 100%" class=3D""><tbody=
class=3D"">
=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>>: Nov 28 06:01PM -0800
</span>
<br class=3D""><br class=3D"">
On Monday, November 28, 2016 at 6:40:18 PM UTC-5, Bryce Glover wrot=
e:<br class=3D"">
> <<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016=
/p0099r1.pdf" class=3D"">http://www.open-std.org/jtc1/sc22/wg21/docs/papers=
/2016/p0099r1.pdf</a>>? <br class=3D"">
> Might it have had something to do with any of the *other* API changes=
<br class=3D"">
> mentioned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 s=
ection? <br class=3D"">
<br class=3D"">
The reason is effectively stated in the proposal, but more detail is <br cl=
ass=3D"">
provided in the Boost.Context documentation <br class=3D"">
<<a href=3D"http://www.boost.org/doc/libs/1_62_0/libs/context/doc/html/c=
ontext/ecv2.html" class=3D"">http://www.boost.org/doc/libs/1_62_0/libs/cont=
ext/doc/html/context/ecv2.html</a>>. <br class=3D"">
That project mirrors this proposal (in that Boost.Context's writer is the <=
br class=3D"">
one who wrote the P0099 proposals).<br class=3D"">
<br class=3D"">
In R0, `execution_context` was internally reference counted. That's what <b=
r class=3D"">
made `current` possible; you could always return an object that stored <br =
class=3D"">
another reference to your current execution context. Also, `current` has to=
<br class=3D"">
actually store the current context in some form of variable accessible from=
<br class=3D"">
within that context.<br class=3D"">
<br class=3D"">
But that requires that the internal construct behind `execution_context` <b=
r class=3D"">
was heap-allocated and reference counted. If you don't need that <br class=
=3D"">
functionality, then it is a performance/resource burden that you cannot <br=
class=3D"">
avoid.<br class=3D"">
<br class=3D"">
Thus, R1 and the current Boost.Context removes this notion. <br class=3D"">
`execution_context` becomes a move-only type. If you want it reference <br =
class=3D"">
counted, then you write a wrapper that does that. If you want `current`, <b=
r class=3D"">
then your wrapper will need to make sure that the current context variable =
<br class=3D"">
is set when resuming the context.<br class=3D"">
<br class=3D"">
Basically, `execution_context` is a *much* lower-level construct now.<br cl=
ass=3D"">
<br class=3D"">
> =E2=80=98Apology=E2=80=99 section and/or elsewhere. Is that document =
supposed to answer <br class=3D"">
> the question I originally posed, or would the answer to my initial <br=
class=3D"">
> head-scratch be something else=E2=80=A6? <br class=3D"">
<br class=3D"">
Not really. P0444 is more a thought experiment; by the authors' own <br cla=
ss=3D"">
admission, they don't have the resources and ability to implement anything =
<br class=3D"">
they're talking about. It doesn't present a fully fleshed out proposal, not=
<br class=3D"">
to the point of explicit API calls.<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>>: Nov 29 10:26AM +0100
</span>
<br class=3D""><br class=3D"">
> <<a href=3D"http://www.boost.org/doc/libs/1_62_0/libs/conte=
xt/doc/html/context/ecv2.html" class=3D"">http://www.boost.org/doc/libs/1_6=
2_0/libs/context/doc/html/context/ecv2.html</a>>.<br class=3D"">
> That project mirrors this proposal (in that Boost.Context's writer is =
the<br class=3D"">
> one who wrote the P0099 proposals).<br class=3D"">
<br class=3D"">
(the proposal mirrors the project)<br class=3D"">
<br class=3D"">
the implementation of R1 in boost.context simply stores the stack pointer<b=
r class=3D"">
inside of execution_context. if a context is suspended, relevant registers<=
br class=3D"">
are pushed onto the stack and a new instance of execution_context (holding<=
br class=3D"">
the stack pointer) is forwarded to the resumed context.<br class=3D"">
if a context is resumed the internal pointer of execution_context gets<br c=
lass=3D"">
assigned to the stack pointer, the content of the relevant registers is<br =
class=3D"">
popped from the stack and the context gets executed.<br class=3D"">
in other words, stack pointers are forwarded between different instances of=
<br class=3D"">
execution_context.<br class=3D"">
<br class=3D"">
implementation of R1 shows a better performance than R0 (maybe better to<br=
class=3D"">
omptimizable by the compiler; no ref-couting)<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://4/#dige=
st_top" class=3D"">Back to top</a>
</div>
=20
<a name=3D"group_thread_2" class=3D""></a><font color=3D"#000000" size=3D=
"3" class=3D"">(snipped=E2=80=A6)</font>
</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><br class=3D""><div class=3D""><br class=3D""></di=
v> Ah, that makes sense=E2=80=89=E2=80=94=E2=80=89and, n=
ow that you mention it, Nicol, I found where the explanation both you and O=
liver gave is referenced in P0099R1: it=E2=80=99s buried at the botto=
m of page 5 in a footnote, so no <i class=3D"">wonder</i> I forgot abo=
ut it, silly me! And, yes, I agree I was just grasping for straws whe=
n I tried looking in related papers for what was, it turns out, so obviousl=
y right under my nose the entire time. In any case, thank you both fo=
r your helpful clarification, and I look forward to seeing where all of thi=
s leads. <br class=3D""><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><div class=3D""><br class=3D"webkit-block-placeholder"></div><div class=
=3D"">P. S.: Has a reference-counted wrapper for the current (confusi=
on and/or pun not intended) version of `execution_context` as presented in =
P0099R1 and implemented in Boost.Context also been proposed for standardiza=
tion yet, by any chance, or are users expected to write their own instances=
of such a wrapper class all by themselves? </div></body></html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1F2AD4FB-F0D1-4744-9FA1-2B0EBA0A4A0D%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1F2AD4FB-F0D1-4744-9FA1-2B0EBA0A4A0D%=
40gmail.com</a>.<br />
--Apple-Mail=_6E6C0B16-B680-4417-8251-F2F7192F3C43--
.
Author: Oliver Kowalke <oliver.kowalke@gmail.com>
Date: Wed, 30 Nov 2016 11:53:55 +0100
Raw View
--001a113f6de8a46a4105428286a7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2016-11-30 2:14 GMT+01:00 Bryce Glover <randomdsdevel@gmail.com>:
> On Nov 29, 2016, at 5:14 PM, std-proposals@isocpp.org wrote:
>
> std-proposals@isocpp.org
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail#%21forum/std-proposals/topics> Google
> Groups
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail/#%21overview>
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail/#%21overview>
> Topic digest
> View all topics
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail#%21forum/std-proposals/topics>
>
> - (snipped=E2=80=A6)
> - Where'd P0099R0's `std::execution_context::current()` Function Go In
> P0099R1 and Why? - 4 Updates
> - (snipped=E2=80=A6)
>
> Where'd P0099R0's `std::execution_context::current()` Function Go In
> P0099R1 and Why?
> <http://groups.google.com/a/isocpp.org/group/std-proposals/t/e1f882f8006a=
f642?utm_source=3Ddigest&utm_medium=3Demail>
> (snipped=E2=80=A6)
> Nicol Bolas <jmckesson@gmail.com>: Nov 28 06:01PM -0800
>
> On Monday, November 28, 2016 at 6:40:18 PM UTC-5, Bryce Glover wrote:
> > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>?
> > Might it have had something to do with any of the *other* API changes
> > mentioned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 se=
ction?
>
> The reason is effectively stated in the proposal, but more detail is
> provided in the Boost.Context documentation
> <http://www.boost.org/doc/libs/1_62_0/libs/context/doc/
> html/context/ecv2.html>.
> That project mirrors this proposal (in that Boost.Context's writer is the
> one who wrote the P0099 proposals).
>
> In R0, `execution_context` was internally reference counted. That's what
> made `current` possible; you could always return an object that stored
> another reference to your current execution context. Also, `current` has
> to
> actually store the current context in some form of variable accessible
> from
> within that context.
>
> But that requires that the internal construct behind `execution_context`
> was heap-allocated and reference counted. If you don't need that
> functionality, then it is a performance/resource burden that you cannot
> avoid.
>
> Thus, R1 and the current Boost.Context removes this notion.
> `execution_context` becomes a move-only type. If you want it reference
> counted, then you write a wrapper that does that. If you want `current`,
> then your wrapper will need to make sure that the current context variabl=
e
> is set when resuming the context.
>
> Basically, `execution_context` is a *much* lower-level construct now.
>
> > =E2=80=98Apology=E2=80=99 section and/or elsewhere. Is that document su=
pposed to answer
> > the question I originally posed, or would the answer to my initial
> > head-scratch be something else=E2=80=A6?
>
> Not really. P0444 is more a thought experiment; by the authors' own
> admission, they don't have the resources and ability to implement anythin=
g
> they're talking about. It doesn't present a fully fleshed out proposal,
> not
> to the point of explicit API calls.
> Oliver Kowalke <oliver.kowalke@gmail.com>: Nov 29 10:26AM +0100
>
> > <http://www.boost.org/doc/libs/1_62_0/libs/context/doc/
> html/context/ecv2.html>.
> > That project mirrors this proposal (in that Boost.Context's writer is t=
he
> > one who wrote the P0099 proposals).
>
> (the proposal mirrors the project)
>
> the implementation of R1 in boost.context simply stores the stack pointer
> inside of execution_context. if a context is suspended, relevant register=
s
> are pushed onto the stack and a new instance of execution_context (holdin=
g
> the stack pointer) is forwarded to the resumed context.
> if a context is resumed the internal pointer of execution_context gets
> assigned to the stack pointer, the content of the relevant registers is
> popped from the stack and the context gets executed.
> in other words, stack pointers are forwarded between different instances =
of
> execution_context.
>
> implementation of R1 shows a better performance than R0 (maybe better to
> omptimizable by the compiler; no ref-couting)
> ack to top
> (snipped=E2=80=A6)
> You received this digest because you're subscribed to tes for this group.
> You can change your settings on the group membership page
> <https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&utm_me=
dium=3Demail#%21forum/std-proposals/join>.To
> unsubscribe from this group and stop receiving emails from it send an ema=
il
> to std-proposals+unsubscribe@isocpp.org.
>
>
> P. S.: Has a reference-counted wrapper for the current (confusion and/or
> pun not intended) version of `execution_context` as presented in P0099R1
> and implemented in Boost.Context also been proposed for standardization
> yet, by any chance, or are users expected to write their own instances of
> such a wrapper class all by themselves?
>
for what reasons do you need a reference counted 'execution_context'? in
order to provide a static function like 'execution_context::current()'?
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2Bwfc1_TwyVxXZNifys83EwO%2BjQ1X-O%3DgH3T265%2=
BVc23JQD%2BZw%40mail.gmail.com.
--001a113f6de8a46a4105428286a7
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=
-11-30 2:14 GMT+01:00 Bryce Glover <span dir=3D"ltr"><<a target=3D"_blan=
k" href=3D"mailto:randomdsdevel@gmail.com">randomdsdevel@gmail.com</a>><=
/span>:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div style=3D"=
word-wrap:break-word"><div><blockquote type=3D"cite"><div>On Nov 29, 2016, =
at 5:14 PM, <a target=3D"_blank" href=3D"mailto:std-proposals@isocpp.org">s=
td-proposals@isocpp.org</a> wrote:</div><br class=3D"gmail-m_-7635327975057=
424600Apple-interchange-newline"><div>
<div style=3D"border-width:1px;border-style:solid;border-color:rgb(211,211,=
211);max-width:850px;font-family:arial,sans-serif">
<div style=3D"background-color:rgb(245,245,245);padding:10px 20px">
<table style=3D"width:100%" cellpadding=3D"0" cellspacing=3D"0">
<tbody>
<tr>
<td style=3D"width:70%">
<span style=3D"font:18px/20px arial;color:rgb(51,51,51)">
<a target=3D"_blank" style=3D"text-decoration:none;color:rgb(=
51,51,51)" href=3D"https://groups.google.com/a/isocpp.org/forum/?utm_source=
=3Ddigest&utm_medium=3Demail#%21forum/std-proposals/topics">
std-proposals@isocpp.org</a>
</span>
</td>
<td style=3D"text-align:right;width:30%">
<span style=3D"font:20px/24px arial"><a target=3D"_blank" href=
=3D"https://groups.google.com/a/isocpp.org/forum/?utm_source=3Ddigest&u=
tm_medium=3Demail/#%21overview" style=3D"color:rgb(221,75,57);text-decorati=
on:none">Google Groups</a></span>
</td>
<td style=3D"width:32px">
<a target=3D"_blank" href=3D"https://groups.google.com/a/isocpp=
..org/forum/?utm_source=3Ddigest&utm_medium=3Demail/#%21overview"><img s=
rc=3D"http://www.google.com/images/icons/product/groups-32.png" style=3D"bo=
rder-width: 0px; border-style: none; border-color: -moz-use-text-color; bor=
der-image: none; vertical-align: middle;"></a>
</td>
</tr>
</tbody>
</table>
</div>
<div style=3D"padding:20px;background-color:rgb(245,245,245)">
<div style=3D"font-family:arial;color:rgb(34,34,34);padding:0px">
<a style=3D"font-size:21px" name=3D"m_-7635327975057424600_digest_top">
=20
=20
Topic digest
=20
</a><br>
<span style=3D"font-size:11px">
<a target=3D"_blank" href=3D"https://groups.google.com/a/isocpp.org/for=
um/?utm_source=3Ddigest&utm_medium=3Demail#%21forum/std-proposals/topic=
s" style=3D"color:rgb(17,85,204);text-decoration:none">View all topics</a>
</span>
</div>
<div style=3D"font:13px/18px arial;color:rgb(34,34,34);padding:0px;margin-b=
ottom:30px">
<ul style=3D"margin-left:3px;padding-left:0px">
=20
<li>(snipped=E2=80=A6)</li>
=20
<li>
<a style=3D"color:rgb(17,85,204);text-decoration:none">
Where'd P0099R0's `std::execution_context::<wbr>current()` Fu=
nction Go In P0099R1 and Why?</a> -
<span style=3D"color:rgb(119,119,119)">4 Updates</span>
</li>
=20
<li>(snipped=E2=80=A6)</li>
=20
</ul>
</div>
=20
<a name=3D"m_-7635327975057424600_group_thread_0"></a><div style=3D"displ=
ay:inline-block;font-family:arial;padding:4px 0px 5px"><a target=3D"_blank"=
style=3D"font-size:21px;color:rgb(17,85,204);text-decoration:none" href=3D=
"http://groups.google.com/a/isocpp.org/group/std-proposals/t/e1f882f8006af6=
42?utm_source=3Ddigest&utm_medium=3Demail">Where'd P0099R0's `s=
td::execution_context::<wbr>current()` Function Go In P0099R1 and Why?
</a>
=20
</div>
<table style=3D"border-collapse:collapse;width:100%"><tbody>
=20
<tr><td style=3D"background-color:rgb(255,255,255);font-family:arial;=
padding:10px 15px;border-width:1px;border-style:solid;border-color:rgb(211,=
211,211)"><font color=3D"#b1b0b0"><span style=3D"font-size:15px">(snipped=
=E2=80=A6)</span></font></td></tr>
=20
<tr><td style=3D"background-color:rgb(255,255,255);color:rgb(46,46,46=
);font-family:arial;padding:10px 15px;border-width:1px;border-style:solid;b=
order-color:rgb(211,211,211)">
<span style=3D"color:rgb(177,176,176);font-size:15px">
Nicol Bolas <<a target=3D"_blank" href=3D"mailto:jmckesson@gma=
il.com">jmckesson@gmail.com</a>>: Nov 28 06:01PM -0800
</span>
<br><span class=3D"gmail-"><br>
On Monday, November 28, 2016 at 6:40:18 PM UTC-5, Bryce Glover wrot=
e:<br></span>
> <<a target=3D"_blank" href=3D"http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2016/p0099r1.pdf">http://www.open-std.org/jtc1/<wbr>sc22/wg21=
/docs/papers/2016/<wbr>p0099r1.pdf</a>>? <br>
> Might it have had something to do with any of the *other* API changes=
<br><span class=3D"gmail-">
> mentioned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 s=
ection? <br>
=C2=A0<br></span><span class=3D"gmail-">
The reason is effectively stated in the proposal, but more detail is <br>
provided in the Boost.Context documentation <br></span>
<<a target=3D"_blank" href=3D"http://www.boost.org/doc/libs/1_62_0/libs/=
context/doc/html/context/ecv2.html">http://www.boost.org/doc/<wbr>libs/1_62=
_0/libs/context/doc/<wbr>html/context/ecv2.html</a>>. <br><span class=3D=
"gmail-">
That project mirrors this proposal (in that Boost.Context's writer is t=
he <br>
one who wrote the P0099 proposals).<br>
=C2=A0<br></span><span class=3D"gmail-">
In R0, `execution_context` was internally reference counted. That's wha=
t <br>
made `current` possible; you could always return an object that stored <br>
another reference to your current execution context. Also, `current` has to=
<br>
actually store the current context in some form of variable accessible from=
<br>
within that context.<br>
=C2=A0<br>
But that requires that the internal construct behind `execution_context` <b=
r>
was heap-allocated and reference counted. If you don't need that <br>
functionality, then it is a performance/resource burden that you cannot <br=
>
avoid.<br>
=C2=A0<br>
Thus, R1 and the current Boost.Context removes this notion. <br>
`execution_context` becomes a move-only type. If you want it reference <br>
counted, then you write a wrapper that does that. If you want `current`, <b=
r>
then your wrapper will need to make sure that the current context variable =
<br>
is set when resuming the context.<br>
=C2=A0<br></span>
Basically, `execution_context` is a *much* lower-level construct now.<span =
class=3D"gmail-"><br>
=C2=A0<br>
> =E2=80=98Apology=E2=80=99 section and/or elsewhere. Is that document =
supposed to answer <br>
> the question I originally posed, or would the answer to my initial <br=
>
> head-scratch be something else=E2=80=A6? <br>
=C2=A0<br>
Not really. P0444 is more a thought experiment; by the authors' own <br=
>
admission, they don't have the resources and ability to implement anyth=
ing <br>
they're talking about. It doesn't present a fully fleshed out propo=
sal, not <br>
to the point of explicit API calls.<br>
</span></td></tr>
=20
<tr><td style=3D"background-color:rgb(255,255,255);color:rgb(46,46,46=
);font-family:arial;padding:10px 15px;border-width:1px;border-style:solid;b=
order-color:rgb(211,211,211)">
<span style=3D"color:rgb(177,176,176);font-size:15px">
Oliver Kowalke <<a target=3D"_blank" href=3D"mailto:oliver.kow=
alke@gmail.com">oliver.kowalke@gmail.com</a>>: Nov 29 10:26AM +0100
</span>
<br><br>
> <<a target=3D"_blank" href=3D"http://www.boost.org/doc/libs=
/1_62_0/libs/context/doc/html/context/ecv2.html">http://www.boost.org/doc/<=
wbr>libs/1_62_0/libs/context/doc/<wbr>html/context/ecv2.html</a>>.<span =
class=3D"gmail-"><br>
> That project mirrors this proposal (in that Boost.Context's writer=
is the<br>
> one who wrote the P0099 proposals).<br>
=C2=A0<br>
(the proposal mirrors the project)<br>
=C2=A0<br>
the implementation of R1 in boost.context simply stores the stack pointer<b=
r>
inside of execution_context. if a context is suspended, relevant registers<=
br>
are pushed onto the stack and a new instance of execution_context (holding<=
br>
the stack pointer) is forwarded to the resumed context.<br>
if a context is resumed the internal pointer of execution_context gets<br>
assigned to the stack pointer, the content of the relevant registers is<br>
popped from the stack and the context gets executed.<br>
in other words, stack pointers are forwarded between different instances of=
<br>
execution_context.<br>
=C2=A0<br>
implementation of R1 shows a better performance than R0 (maybe better to<br=
>
omptimizable by the compiler; no ref-couting)</span></td></tr></tbody></tab=
le><div style=3D"font-size:11px;margin-bottom:40px;margin-top:5px"><a style=
=3D"color:rgb(17,85,204);text-decoration:none">ack to top</a>
</div>
=20
<a name=3D"m_-7635327975057424600_group_thread_2"></a><font color=3D"#000=
000" size=3D"3">(snipped=E2=80=A6)</font>
</div>
<div style=3D"background-color:rgb(245,245,245);padding:5px 20px">
<table cellpadding=3D"0" cellspacing=3D"0" height=3D"28" width=3D"810">
<tbody><tr>
<td style=3D"padding-top:4px;font-family:arial,sans-serif;color:rgb(99,=
99,99);font-size:11px">
=20
You received this digest because you're subscribed to tes for thi=
s group. You can change your settings on the <a target=3D"_blank" style=3D"=
color:rgb(17,85,204);text-decoration:none" href=3D"https://groups.google.co=
m/a/isocpp.org/forum/?utm_source=3Ddigest&utm_medium=3Demail#%21forum/s=
td-proposals/join">group membership page</a>.To unsubscribe from this group=
and stop receiving emails from it send an email to std-proposals+unsubscri=
be@<wbr><a href=3D"http://isocpp.org">isocpp.org</a>.
</td>
</tr></tbody>
</table>
</div>
</div>
</div></blockquote></div><div><br class=3D"gmail-m_-7635327975057424600webk=
it-block-placeholder"></div><div>P. S.: =C2=A0Has a reference-counted wrapp=
er for the current (confusion and/or pun not intended) version of `executio=
n_context` as presented in P0099R1 and implemented in Boost.Context also be=
en proposed for standardization yet, by any chance, or are users expected t=
o write their own instances of such a wrapper class all by themselves? <br>=
</div></div></blockquote><div><br></div><div>for what reasons do you need a=
reference counted 'execution_context'? in order to provide a stati=
c function like 'execution_context::current()'?<br></div></div><br>=
</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_TwyVxXZNifys83EwO%2BjQ1X-O%=
3DgH3T265%2BVc23JQD%2BZw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwf=
c1_TwyVxXZNifys83EwO%2BjQ1X-O%3DgH3T265%2BVc23JQD%2BZw%40mail.gmail.com</a>=
..<br />
--001a113f6de8a46a4105428286a7--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 30 Nov 2016 07:58:32 -0800 (PST)
Raw View
------=_Part_11883_250170575.1480521512406
Content-Type: multipart/alternative;
boundary="----=_Part_11884_660724605.1480521512406"
------=_Part_11884_660724605.1480521512406
Content-Type: text/plain; charset=UTF-8
On Wednesday, November 30, 2016 at 5:54:18 AM UTC-5, Oliver Kowalke wrote:
>
> 2016-11-30 2:14 GMT+01:00 Bryce Glover <random...@gmail.com <javascript:>>
> :
>
>> On Nov 29, 2016, at 5:14 PM, std-pr...@isocpp.org <javascript:> wrote:
>> You received this digest because you're subscribed to tes for this group.
>> You can change your settings on the group membership page
>> <https://groups.google.com/a/isocpp.org/forum/?utm_source=digest&utm_medium=email#%21forum/std-proposals/join>.To
>> unsubscribe from this group and stop receiving emails from it send an email
>> to std-proposals+unsubscribe@isocpp.org.
>>
>>
>> P. S.: Has a reference-counted wrapper for the current (confusion and/or
>> pun not intended) version of `execution_context` as presented in P0099R1
>> and implemented in Boost.Context also been proposed for standardization
>> yet, by any chance, or are users expected to write their own instances of
>> such a wrapper class all by themselves?
>>
>
> for what reasons do you need a reference counted 'execution_context'? in
> order to provide a static function like 'execution_context::current()'?
>
>
I can't speak for him, but I feel that the main reason for wanting
standardized higher-level constructs is for interoperability. Some people
really do want/need `current` to work, which ultimately requires that all
transference of context execution be done via wrappers around the
lower-level constructs. It would be very unfortunate if my wrappers
couldn't interoperate with someone else's wrappers, even though they're
doing the same thing.
It is very good that people can go low-level when they need to. But we
still need solid interop at the higher levels too. Much like we have
function pointers, but we also have virtual functions too, so that my
classes can derive from your classes.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8e9031a1-7d1d-4b37-ace0-456d150d9999%40isocpp.org.
------=_Part_11884_660724605.1480521512406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, November 30, 2016 at 5:54:18 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 d=
ir=3D"ltr"><div><div class=3D"gmail_quote">2016-11-30 2:14 GMT+01:00 Bryce =
Glover <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"NHMAyXZzBQAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">random...@gmail.com</a>></span>:<br><blockquote =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex" class=3D"gmail_quote"><div style=3D"word-wrap:break-word"><=
div><blockquote type=3D"cite"><div>On Nov 29, 2016, at 5:14 PM, <a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"NHMAyXZzBQAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">std-pr...@isoc=
pp.org</a> wrote:</div><div><div style=3D"border-width:1px;border-style:sol=
id;border-color:rgb(211,211,211);max-width:850px;font-family:arial,sans-ser=
if"><div style=3D"background-color:rgb(245,245,245);padding:5px 20px"><tabl=
e width=3D"810" height=3D"28" cellspacing=3D"0" cellpadding=3D"0"><tbody><t=
r><td style=3D"padding-top:4px;font-family:arial,sans-serif;color:rgb(99,99=
,99);font-size:11px">
=20
You received this digest because you're subscribed to tes for thi=
s group. You can change your settings on the <a style=3D"color:rgb(17,85,20=
4);text-decoration:none" href=3D"https://groups.google.com/a/isocpp.org/for=
um/?utm_source=3Ddigest&utm_medium=3Demail#%21forum/std-proposals/join"=
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https:/=
/groups.google.com/a/isocpp.org/forum/?utm_source\x3ddigest\x26utm_medium\x=
3demail#%21forum/std-proposals/join';return true;" onclick=3D"this.href=
=3D'https://groups.google.com/a/isocpp.org/forum/?utm_source\x3ddigest\=
x26utm_medium\x3demail#%21forum/std-proposals/join';return true;">group=
membership page</a>.To unsubscribe from this group and stop receiving emai=
ls from it send an email to std-proposals+unsubscribe@<a href=3D"http://iso=
cpp.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fisocpp.org\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNHaIcX84r8AUHgx9Q4pR00LZ1llsQ';return true;" onclic=
k=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fisocpp.or=
g\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHaIcX84r8AUHgx9Q4pR00LZ1llsQ'=
;return true;">isoc<wbr>pp.org</a>.
</td>
</tr></tbody>
</table>
</div>
</div>
</div></blockquote></div><div><br></div><div>P. S.: =C2=A0Has a reference-c=
ounted wrapper for the current (confusion and/or pun not intended) version =
of `execution_context` as presented in P0099R1 and implemented in Boost.Con=
text also been proposed for standardization yet, by any chance, or are user=
s expected to write their own instances of such a wrapper class all by them=
selves? <br></div></div></blockquote><div><br></div><div>for what reasons d=
o you need a reference counted 'execution_context'? in order to pro=
vide a static function like 'execution_context::current()'<wbr>?<br=
></div></div><br></div></div></blockquote><div><br>I can't speak for hi=
m, but I feel that the main reason for wanting standardized higher-level co=
nstructs is for interoperability. Some people really do want/need `current`=
to work, which ultimately requires that all transference of context execut=
ion be done via wrappers around the lower-level constructs. It would be ver=
y unfortunate if my wrappers couldn't interoperate with someone else=
9;s wrappers, even though they're doing the same thing.<br><br>It is ve=
ry good that people can go low-level when they need to. But we still need s=
olid interop at the higher levels too. Much like we have function pointers,=
but we also have virtual functions too, so that my classes can derive from=
your classes.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8e9031a1-7d1d-4b37-ace0-456d150d9999%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8e9031a1-7d1d-4b37-ace0-456d150d9999=
%40isocpp.org</a>.<br />
------=_Part_11884_660724605.1480521512406--
------=_Part_11883_250170575.1480521512406--
.
Author: Bryce Glover <randomdsdevel@gmail.com>
Date: Thu, 1 Dec 2016 19:43:35 -0500
Raw View
--Apple-Mail=_A3E8D961-CB7D-4EB7-985E-0B74EC15D49F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
@Oliver: =20
> [F]or what reasons do you need a reference counted =E2=80=98execution_con=
text=E2=80=99? [I]n order to provide a static function like =E2=80=98execu=
tion_context::current()=E2=80=99? =20
Like Nicol said: =20
> I can't speak for him, but I feel that the main reason for wanting standa=
rdized higher-level constructs is for interoperability. Some people really =
do want/need `current` to work, which ultimately requires that all transfer=
ence of context execution be done via wrappers around the lower-level const=
ructs. It would be very unfortunate if my wrappers couldn't interoperate wi=
th someone else's wrappers, even though they're doing the same thing.
>=20
> It is very good that people can go low-level when they need to. But we st=
ill need solid interop at the higher levels too. Much like we have function=
pointers, but we also have virtual functions too, so that my classes can d=
erive from your classes.
Also, I may eventually have a use case for `execution_context`s once I fini=
sh fleshing out a little pet project <https://github.com/RandomDSdevel/Rand=
omDSdevel-Evolution/blob/objcpprc/Proposals/P0001R0D0.md> that, as evidence=
d by some of the contents of my active posts here on one or more of the WG2=
1 reflectors in the past, I=E2=80=99ve been thinking about for quite a whil=
e now. (The basic construct in that framework whose internals would benefi=
t from using something like `execution_context` would be a C++ equivalent o=
f Objective-C=E2=80=99s run-time=E2=80=93internal `objc_msgSend()` intrinsi=
c function <https://developer.apple.com/reference/objectivec/1456712-objc_m=
sgsend> which, as shown by its source code <https://opensource.apple.com/s=
ource/objc4/objc4-647/runtime/message.h>*, messes with the stack a bit.) S=
aid idea will probably lack an implementation for the foreseeable future, t=
hough, as I=E2=80=99m in a bit over my head considering such an effort at t=
his stage in my life. In the meantime, I=E2=80=99ll keep looking forward t=
o more progress on at least the Coroutines and Reflection TSes. =20
=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com
*Note that this link=E2=80=99s target=E2=80=99s host server appears to be d=
own last I checked, and I=E2=80=99ve reported this to its owner. In the me=
antime, there are enough results for =E2=80=98objc_msgSend() implementation=
=E2=80=99 on Google <https://www.google.com/search?num=3D30&client=3Dsafari=
&rls=3Den&q=3Dobjc_msgSend+implementation&oq=3Dobjc_msgSend+implementation&=
gs_l=3Dserp.3..0.15130.17609.0.18151.15.6.0.9.9.0.148.588.0j5.5.0....0...1c=
..1.64.serp..1.14.610...0i22i30k1.4zb_6m3bhP8> that quote this link=E2=80=99=
s target file=E2=80=99s contents. =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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/92275E91-CA69-4DFC-938B-390DE4C69DE0%40gmail.com=
..
--Apple-Mail=_A3E8D961-CB7D-4EB7-985E-0B74EC15D49F
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"">@O=
liver: </div><blockquote type=3D"cite" class=3D"">[F]or what reasons =
do you need a reference counted =E2=80=98execution_context=E2=80=99? =
[I]n order to provide a static function like =E2=80=98execution_context::cu=
rrent()=E2=80=99? </blockquote><br class=3D""><div class=3D"">Like Ni=
col said: </div><div class=3D""><br class=3D""></div><div class=3D"">=
<blockquote type=3D"cite" class=3D"">I can't speak for him, but I feel that=
the main reason for wanting standardized higher-level constructs is for in=
teroperability. Some people really do want/need `current` to work, which ul=
timately requires that all transference of context execution be done via wr=
appers around the lower-level constructs. It would be very unfortunate if m=
y wrappers couldn't interoperate with someone else's wrappers, even though =
they're doing the same thing.</blockquote><blockquote type=3D"cite" class=
=3D""><br class=3D""></blockquote><blockquote type=3D"cite" class=3D"">It i=
s very good that people can go low-level when they need to. But we still ne=
ed solid interop at the higher levels too. Much like we have function point=
ers, but we also have virtual functions too, so that my classes can derive =
from your classes.</blockquote><br class=3D""></div><div class=3D"">Also, I=
may eventually have a use case for `execution_context`s once I finish fles=
hing out <a href=3D"https://github.com/RandomDSdevel/RandomDSdevel-Evo=
lution/blob/objcpprc/Proposals/P0001R0D0.md" class=3D"">a little pet projec=
t</a> that, as evidenced by some of the contents of my active posts he=
re on one or more of the WG21 reflectors in the past, I=E2=80=99ve been thi=
nking about for quite a while now. (The basic construct in that frame=
work whose internals would benefit from using something like `execution_con=
text` would be a C++ equivalent of <a href=3D"https://developer.apple.=
com/reference/objectivec/1456712-objc_msgsend" class=3D"">Objective-C=E2=80=
=99s run-time=E2=80=93internal `objc_msgSend()` intrinsic function</a> =
; which, as shown by <a href=3D"https://opensource.apple.com/source/ob=
jc4/objc4-647/runtime/message.h" class=3D"">its source code</a>*, messes wi=
th the stack a bit.) Said idea will probably lack an implementation f=
or the foreseeable future, though, as I=E2=80=99m in a bit over my head con=
sidering such an effort at this stage in my life. In the meantime, I=
=E2=80=99ll keep looking forward to more progress on at least the Coroutine=
s and Reflection TSes. </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><div class=3D""><br class=3D"webkit-block-placeholder"></div><div class=
=3D"">*Note that this link=E2=80=99s target=E2=80=99s host server appears t=
o be down last I checked, and I=E2=80=99ve reported this to its owner. &nbs=
p;In the meantime, there are <a href=3D"https://www.google.com/search?=
num=3D30&client=3Dsafari&rls=3Den&q=3Dobjc_msgSend+implementati=
on&oq=3Dobjc_msgSend+implementation&gs_l=3Dserp.3..0.15130.17609.0.=
18151.15.6.0.9.9.0.148.588.0j5.5.0....0...1c.1.64.serp..1.14.610...0i22i30k=
1.4zb_6m3bhP8" class=3D"">enough results for =E2=80=98objc_msgSend() implem=
entation=E2=80=99 on Google</a> that quote this link=E2=80=99s target =
file=E2=80=99s contents. </div></body></html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/92275E91-CA69-4DFC-938B-390DE4C69DE0%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/92275E91-CA69-4DFC-938B-390DE4C69DE0%=
40gmail.com</a>.<br />
--Apple-Mail=_A3E8D961-CB7D-4EB7-985E-0B74EC15D49F--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Fri, 2 Dec 2016 04:38:02 -0800 (PST)
Raw View
------=_Part_714_2094508848.1480682282782
Content-Type: multipart/alternative;
boundary="----=_Part_715_480395115.1480682282782"
------=_Part_715_480395115.1480682282782
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, November 28, 2016 at 11:35:01 PM UTC, Bryce Glover wrote:
>
> I noticed that the =E2=80=98Revision History=E2=80=99 section of P00=
99R1=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf> men=
tions=20
> that the static `current()` member function present in P0099R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=
=80=99s=20
> version of the class `std::execution_context` which both versions of the=
=20
> proposal present for possible addition to the C++ standard was removed in=
=20
> P0099R1=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>=E2=
=80=99s=20
> version of it. This, however, strikes me as quite puzzling, as I found=
=20
> that `std::execution_context`=E2=80=99s API was *much* more understandabl=
e *with* that=20
> static member function included than without it. This is because I find =
it=20
> somewhat easier to keep track of an `std::execution_context` when I can s=
ee=20
> exactly where it was explicitly created than when the compiler generates =
it=20
> at a point in a program=E2=80=99s execution that some, myself included, m=
ight find=20
> hard to pin down. I know that one isn=E2=80=99t supposed to see and/or u=
se=20
> `std::execution_context` all that often, but I *also* don=E2=80=99t see a=
ny=20
> benefits to this rather baffling API change beside the fact that it makes=
=20
> the class even *more* of a niche tool than it already is. What, then,=20
> was the original motivation for removing P0099R0=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=
=80=99s=20
> `std::execution_context::current()` from P0099R1=20
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>?=20
> Might it have had something to do with any of the *other* API changes=20
> mentioned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 sect=
ion? =20
>
As someone that has strongly argued against current() on grounds of=20
performance, elegance and correctness, I'm very happy that the authors=20
made this change.=20
Now, as per documentation, an execution context has pointer semantics=20
represent a reference to a *suspended* execution context (and empty=20
otherwise) [1]. As the current context can't be possibly suspended, there=
=20
is no possible meaning for the current() function. There is also no need=
=20
for it, as you can't do anything with the current context. To switch to=20
another context you just need a pointer to that context; how you get it is=
=20
up to the application.
I'm also happy that the authors added support for 'yield with current=20
continuation' in the form of operator()(std::invoke_ontop_arg,...). This,=
=20
in addition to being a powerful context composition operator allow seamless=
=20
inter-operation with std::future without any compiler support (i.e. await=
=20
can be a normal function instead of a language keyword).
-- gpd
[1] another way to see this is that a context is the same as a 'one shot=20
continuation'. As the current continuation changes after every executed=20
instruction, the only way to actually capture it is to suspend the=20
executing Thread of Execution and switching to another via=20
context::operator().
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cfd7cd82-080c-404e-8345-b75d96f0c8cf%40isocpp.or=
g.
------=_Part_715_480395115.1480682282782
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, November 28, 2016 at 11:35:01 PM UTC, 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=A0I noticed that the =E2=80=98Revisi=
on History=E2=80=99 section of=C2=A0<a href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2016/p0099r1.pdf" target=3D"_blank" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%=
2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pd=
f\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2F=
p0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2=
PhAVg';return true;">P0099R1</a>=C2=A0mentions that the static `current=
()` member function present in=C2=A0<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\x3dhttp%3A%2F%=
2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pd=
f\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA'=
;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2F=
p0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbKJkd0frHuXT9k=
PA1dA';return true;">P0099R0</a>=E2=80=99s version of the class `std::e=
xecution_context` which both versions of the proposal present for possible =
addition to the C++ standard was removed in=C2=A0<a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x=
3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016=
%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzK=
CZ2PhAVg';return true;" onclick=3D"this.href=3D'http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpap=
ers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKck=
YxmTsvtAzKCZ2PhAVg';return true;">P0099R1</a>=E2=80=99s version of it. =
=C2=A0This, however, strikes me as quite puzzling, as I found that `std::ex=
ecution_context`=E2=80=99s API was <i>much</i>=C2=A0more understandable <i>=
with</i>=C2=A0that static member function included than without it. =C2=A0T=
his is because I find it somewhat easier to keep track of an `std::executio=
n_context` when I can see exactly where it was explicitly created than when=
the compiler generates it at a point in a program=E2=80=99s execution that=
some, myself included, might find hard to pin down. =C2=A0I know that one =
isn=E2=80=99t supposed to see and/or use `std::execution_context` all that =
often, but I <i>also</i>=C2=A0don=E2=80=99t see any benefits to this rather=
baffling API change beside the fact that it makes the class even <i>more</=
i>=C2=A0of a niche tool than it already is. =C2=A0What, then, was the origi=
nal motivation for removing=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2015/p0099r0.pdf" target=3D"_blank" rel=3D"nofollow" on=
mousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fw=
ww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';re=
turn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp=
%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp00=
99r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1=
dA';return true;">P0099R0</a>=E2=80=99s `std::execution_context::<wbr>c=
urrent()` from=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2016/p0099r1.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.o=
rg%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true;" o=
nclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.=
open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';retur=
n true;">P0099R1</a>? =C2=A0Might it have had something to do with any of t=
he <i>other</i>=C2=A0API changes mentioned in the latter=E2=80=99s =E2=80=
=98Revision History=E2=80=99 section? =C2=A0</div></div></blockquote><div><=
br>As someone that has strongly argued against current() on grounds of perf=
ormance, elegance and correctness,=C2=A0 I'm very happy that the author=
s made this change. <br></div><br>Now, as per documentation, an execution c=
ontext has pointer semantics represent a reference to a *suspended* executi=
on context (and empty otherwise) [1]. As the current context can't be p=
ossibly suspended, there is no possible meaning for the current() function.=
=C2=A0 There is also no need for it, as you can't do anything with the =
current context. To switch to another context you just need a pointer to th=
at context; how you get it is up to the application.<br><br>I'm also ha=
ppy that the authors added support for 'yield with current continuation=
' in the form of operator()(std::invoke_ontop_arg,...). This, in additi=
on to being a powerful context composition operator allow seamless inter-op=
eration with std::future without any compiler support (i.e. await can be a =
normal function instead of a language keyword).<br><br>-- gpd<br><br>[1] an=
other way to see this is that a context is the same as a 'one shot cont=
inuation'. As the current continuation changes after every executed ins=
truction, the only way to actually capture it is to suspend the executing T=
hread of Execution and switching to another via context::operator().<br></d=
iv>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cfd7cd82-080c-404e-8345-b75d96f0c8cf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cfd7cd82-080c-404e-8345-b75d96f0c8cf=
%40isocpp.org</a>.<br />
------=_Part_715_480395115.1480682282782--
------=_Part_714_2094508848.1480682282782--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 2 Dec 2016 09:07:38 -0800 (PST)
Raw View
------=_Part_853_1085504018.1480698458791
Content-Type: multipart/alternative;
boundary="----=_Part_854_1023519671.1480698458791"
------=_Part_854_1023519671.1480698458791
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, December 2, 2016 at 7:38:02 AM UTC-5, Giovanni Piero Deretta=20
wrote:
>
> On Monday, November 28, 2016 at 11:35:01 PM UTC, Bryce Glover wrote:
>>
>> I noticed that the =E2=80=98Revision History=E2=80=99 section of P0=
099R1=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf> me=
ntions=20
>> that the static `current()` member function present in P0099R0=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=
=80=99s=20
>> version of the class `std::execution_context` which both versions of the=
=20
>> proposal present for possible addition to the C++ standard was removed i=
n=20
>> P0099R1=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>=E2=
=80=99s=20
>> version of it. This, however, strikes me as quite puzzling, as I found=
=20
>> that `std::execution_context`=E2=80=99s API was *much* more understandab=
le *with* that=20
>> static member function included than without it. This is because I find=
it=20
>> somewhat easier to keep track of an `std::execution_context` when I can =
see=20
>> exactly where it was explicitly created than when the compiler generates=
it=20
>> at a point in a program=E2=80=99s execution that some, myself included, =
might find=20
>> hard to pin down. I know that one isn=E2=80=99t supposed to see and/or =
use=20
>> `std::execution_context` all that often, but I *also* don=E2=80=99t see =
any=20
>> benefits to this rather baffling API change beside the fact that it make=
s=20
>> the class even *more* of a niche tool than it already is. What, then,=
=20
>> was the original motivation for removing P0099R0=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=E2=
=80=99s=20
>> `std::execution_context::current()` from P0099R1=20
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>?=
=20
>> Might it have had something to do with any of the *other* API changes=
=20
>> mentioned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 sec=
tion? =20
>>
>
> As someone that has strongly argued against current() on grounds of=20
> performance, elegance and correctness, I'm very happy that the authors=
=20
> made this change.=20
>
> Now, as per documentation, an execution context has pointer semantics=20
> represent a reference to a *suspended* execution context (and empty=20
> otherwise) [1]. As the current context can't be possibly suspended, there=
=20
> is no possible meaning for the current() function. There is also no need=
=20
> for it, as you can't do anything with the current context. To switch to=
=20
> another context you just need a pointer to that context; how you get it i=
s=20
> up to the application.
>
I'm also happy that the authors added support for 'yield with current=20
> continuation' in the form of operator()(std::invoke_ontop_arg,...). This,=
=20
> in addition to being a powerful context composition operator allow seamle=
ss=20
> inter-operation with std::future without any compiler support (i.e. await=
=20
> can be a normal function instead of a language keyword).
>
.... I fail to see how that has anything to do with `co_await` or `future`.
`co_await` is primarily about halting the current function, generating a=20
promise object to represent the eventual return value, returning a "future"=
=20
object, and scheduling the continuation of the current function based on=20
the result of an expression that has been passed to you.
Switching contexts doesn't halt just the current function; it halts the=20
entire context. The only way those two can be the same thing is if the=20
caller called the function as a separate execution context. And like 95% of=
=20
the point of `co_await` is that the caller of such a continuation *doesn't=
=20
have to know* that it's doing continuation stuff. It calls it just like a=
=20
regular function.
Now personally, I don't care much for `co_await`. I much prefer=20
context-based switching, and `co_await` is really terrible at handling=20
anything more complex than a single function. But you can't deny that the=
=20
language feature requires much less explicit work from the user.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/97ee710d-03b3-4db5-8e57-16675dc26be0%40isocpp.or=
g.
------=_Part_854_1023519671.1480698458791
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 2, 2016 at 7:38:02 AM UTC-5, Giovanni =
Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Monday, November 28, 2016 at 11:35:01 PM UTC, Bryce Glover wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wor=
d"><div>=C2=A0 =C2=A0 =C2=A0I noticed that the =E2=80=98Revision History=E2=
=80=99 section of=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2016/p0099r1.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2F=
www.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';r=
eturn true;">P0099R1</a>=C2=A0mentions that the static `current()` member f=
unction present in=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2015/p0099r0.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2F=
www.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';r=
eturn true;">P0099R0</a>=E2=80=99s version of the class `std::execution_con=
text` which both versions of the proposal present for possible addition to =
the C++ standard was removed in=C2=A0<a href=3D"http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2016/p0099r1.pdf" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.p=
df\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg'=
;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3d=
http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2=
Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ=
2PhAVg';return true;">P0099R1</a>=E2=80=99s version of it. =C2=A0This, =
however, strikes me as quite puzzling, as I found that `std::execution_cont=
ext`=E2=80=99s API was <i>much</i>=C2=A0more understandable <i>with</i>=C2=
=A0that static member function included than without it. =C2=A0This is beca=
use I find it somewhat easier to keep track of an `std::execution_context` =
when I can see exactly where it was explicitly created than when the compil=
er generates it at a point in a program=E2=80=99s execution that some, myse=
lf included, might find hard to pin down. =C2=A0I know that one isn=E2=80=
=99t supposed to see and/or use `std::execution_context` all that often, bu=
t I <i>also</i>=C2=A0don=E2=80=99t see any benefits to this rather baffling=
API change beside the fact that it makes the class even <i>more</i>=C2=A0o=
f a niche tool than it already is. =C2=A0What, then, was the original motiv=
ation for removing=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/d=
ocs/papers/2015/p0099r0.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2F=
www.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';r=
eturn true;">P0099R0</a>=E2=80=99s `std::execution_context::<wbr>current()`=
from=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20=
16/p0099r1.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1=
%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true;" onclick=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.=
org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true;">=
P0099R1</a>? =C2=A0Might it have had something to do with any of the <i>oth=
er</i>=C2=A0API changes mentioned in the latter=E2=80=99s =E2=80=98Revision=
History=E2=80=99 section? =C2=A0</div></div></blockquote><div><br>As someo=
ne that has strongly argued against current() on grounds of performance, el=
egance and correctness,=C2=A0 I'm very happy that the authors made this=
change. <br></div><br>Now, as per documentation, an execution context has =
pointer semantics represent a reference to a *suspended* execution context =
(and empty otherwise) [1]. As the current context can't be possibly sus=
pended, there is no possible meaning for the current() function.=C2=A0 Ther=
e is also no need for it, as you can't do anything with the current con=
text. To switch to another context you just need a pointer to that context;=
how you get it is up to the application.<br></div></blockquote><div><br><b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I=
'm also happy that the authors added support for 'yield with curren=
t continuation' in the form of operator()(std::invoke_ontop_<wbr>arg,..=
..). This, in addition to being a powerful context composition operator allo=
w seamless inter-operation with std::future without any compiler support (i=
..e. await can be a normal function instead of a language keyword).<br></div=
></blockquote><div><br>... I fail to see how that has anything to do with `=
co_await` or `future`.<br><br>`co_await` is primarily about halting the cur=
rent function, generating a promise object to represent the eventual return=
value, returning a "future" object, and scheduling the continuat=
ion of the current function based on the result of an expression that has b=
een passed to you.<br><br>Switching contexts doesn't halt just the curr=
ent function; it halts the entire context. The only way those two can be th=
e same thing is if the caller called the function as a separate execution c=
ontext. And like 95% of the point of `co_await` is that the caller of such =
a continuation <i>doesn't have to know</i> that it's doing continua=
tion stuff. It calls it just like a regular function.</div><br>Now personal=
ly, I don't care much for `co_await`. I much prefer context-based switc=
hing, and `co_await` is really terrible at handling anything more complex t=
han a single function. But you can't deny that the language feature req=
uires much less explicit work from the user.<br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/97ee710d-03b3-4db5-8e57-16675dc26be0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/97ee710d-03b3-4db5-8e57-16675dc26be0=
%40isocpp.org</a>.<br />
------=_Part_854_1023519671.1480698458791--
------=_Part_853_1085504018.1480698458791--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Fri, 2 Dec 2016 17:06:21 -0800 (PST)
Raw View
------=_Part_1004_1040038033.1480727181402
Content-Type: multipart/alternative;
boundary="----=_Part_1005_663117309.1480727181403"
------=_Part_1005_663117309.1480727181403
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, December 2, 2016 at 5:07:38 PM UTC, Nicol Bolas wrote:
>
> On Friday, December 2, 2016 at 7:38:02 AM UTC-5, Giovanni Piero Deretta=
=20
> wrote:
>>
>> On Monday, November 28, 2016 at 11:35:01 PM UTC, Bryce Glover wrote:
>>>
>>> I noticed that the =E2=80=98Revision History=E2=80=99 section of P=
0099R1=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf> m=
entions=20
>>> that the static `current()` member function present in P0099R0=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=
=E2=80=99s=20
>>> version of the class `std::execution_context` which both versions of th=
e=20
>>> proposal present for possible addition to the C++ standard was removed =
in=20
>>> P0099R1=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>=
=E2=80=99s=20
>>> version of it. This, however, strikes me as quite puzzling, as I found=
=20
>>> that `std::execution_context`=E2=80=99s API was *much* more understanda=
ble=20
>>> *with* that static member function included than without it. This is=
=20
>>> because I find it somewhat easier to keep track of an=20
>>> `std::execution_context` when I can see exactly where it was explicitly=
=20
>>> created than when the compiler generates it at a point in a program=E2=
=80=99s=20
>>> execution that some, myself included, might find hard to pin down. I k=
now=20
>>> that one isn=E2=80=99t supposed to see and/or use `std::execution_conte=
xt` all that=20
>>> often, but I *also* don=E2=80=99t see any benefits to this rather baffl=
ing API=20
>>> change beside the fact that it makes the class even *more* of a niche=
=20
>>> tool than it already is. What, then, was the original motivation for=
=20
>>> removing P0099R0=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf>=
=E2=80=99s=20
>>> `std::execution_context::current()` from P0099R1=20
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf>?=
=20
>>> Might it have had something to do with any of the *other* API changes=
=20
>>> mentioned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 se=
ction? =20
>>>
>>
>> As someone that has strongly argued against current() on grounds of=20
>> performance, elegance and correctness, I'm very happy that the authors=
=20
>> made this change.=20
>>
>> Now, as per documentation, an execution context has pointer semantics=20
>> represent a reference to a *suspended* execution context (and empty=20
>> otherwise) [1]. As the current context can't be possibly suspended, ther=
e=20
>> is no possible meaning for the current() function. There is also no nee=
d=20
>> for it, as you can't do anything with the current context. To switch to=
=20
>> another context you just need a pointer to that context; how you get it =
is=20
>> up to the application.
>>
>
>
>
> I'm also happy that the authors added support for 'yield with current=20
>> continuation' in the form of operator()(std::invoke_ontop_arg,...). This=
,=20
>> in addition to being a powerful context composition operator allow seaml=
ess=20
>> inter-operation with std::future without any compiler support (i.e. awai=
t=20
>> can be a normal function instead of a language keyword).
>>
>
> ... I fail to see how that has anything to do with `co_await` or `future`=
..
>
> `co_await` is primarily about halting the current function, generating a=
=20
> promise object to represent the eventual return value, returning a "futur=
e"=20
> object, and scheduling the continuation of the current function based on=
=20
> the result of an expression that has been passed to you.
>
>
Co-await is about making async heavy code more sane. It is limited to only=
=20
suspending a single stack frame and always yielding to the calling=20
function, but these are not desirable properties and are just an artefact=
=20
of the specific compilation strategy it is designed for.
=20
> Switching contexts doesn't halt just the current function; it halts the=
=20
> entire context.=20
>
That is, it context can suspend N nested function frames. For N=3D1 it=20
reduces to the await scenario.
=20
> The only way those two can be the same thing is if the caller called the=
=20
> function as a separate execution context. And like 95% of the point of=20
> `co_await` is that the caller of such a continuation *doesn't have to=20
> know* that it's doing continuation stuff. It calls it just like a regular=
=20
> function.
> Now personally, I don't care much for `co_await`. I much prefer=20
> context-based switching, and `co_await` is really terrible at handling=20
> anything more complex than a single function. But you can't deny that the=
=20
> language feature requires much less explicit work from the user.
>
it is easy to write a wrapper function that allows using the exact same=20
syntax as the builtin await (except that await becomes a function object=20
instead of a keyword). The standard should provide it and it wouldn't=20
require any more explicit work for the user than a builtin await.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b0d5b54d-0f55-4f3a-bbcf-de1e4ef90eb4%40isocpp.or=
g.
------=_Part_1005_663117309.1480727181403
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 2, 2016 at 5:07:38 PM UTC, Nicol Bolas=
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">On Fri=
day, December 2, 2016 at 7:38:02 AM UTC-5, Giovanni Piero Deretta wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, November 2=
8, 2016 at 11:35:01 PM UTC, Bryce Glover wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div style=3D"word-wrap:break-word"><div>=C2=A0 =C2=A0 =C2=A0I =
noticed that the =E2=80=98Revision History=E2=80=99 section of=C2=A0<a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf" re=
l=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
nnneVgKckYxmTsvtAzKCZ2PhAVg';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true;">P0099R1</a>=C2=A0m=
entions that the static `current()` member function present in=C2=A0<a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" re=
l=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2015%2Fp0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
oRShmb9IbKJkd0frHuXT9kPA1dA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true;">P0099R0</a>=E2=80=
=99s version of the class `std::execution_context` which both versions of t=
he proposal present for possible addition to the C++ standard was removed i=
n=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p=
0099r1.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fs=
c22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26=
usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxmTsvtAzKCZ2PhAVg';return true;">P009=
9R1</a>=E2=80=99s version of it. =C2=A0This, however, strikes me as quite p=
uzzling, as I found that `std::execution_context`=E2=80=99s API was <i>much=
</i>=C2=A0more understandable <i>with</i>=C2=A0that static member function =
included than without it. =C2=A0This is because I find it somewhat easier t=
o keep track of an `std::execution_context` when I can see exactly where it=
was explicitly created than when the compiler generates it at a point in a=
program=E2=80=99s execution that some, myself included, might find hard to=
pin down. =C2=A0I know that one isn=E2=80=99t supposed to see and/or use `=
std::execution_context` all that often, but I <i>also</i>=C2=A0don=E2=80=99=
t see any benefits to this rather baffling API change beside the fact that =
it makes the class even <i>more</i>=C2=A0of a niche tool than it already is=
.. =C2=A0What, then, was the original motivation for removing=C2=A0<a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0099r0.pdf" re=
l=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2015%2Fp0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF=
oRShmb9IbKJkd0frHuXT9kPA1dA';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0099r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNFoRShmb9IbKJkd0frHuXT9kPA1dA';return true;">P0099R0</a>=E2=80=
=99s `std::execution_context::<wbr>current()` from=C2=A0<a href=3D"http://w=
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0099r1.pdf" rel=3D"nofollo=
w" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers=
%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnnneVgKckYxm=
TsvtAzKCZ2PhAVg';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdoc=
s%2Fpapers%2F2016%2Fp0099r1.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHnn=
neVgKckYxmTsvtAzKCZ2PhAVg';return true;">P0099R1</a>? =C2=A0Might it ha=
ve had something to do with any of the <i>other</i>=C2=A0API changes mentio=
ned in the latter=E2=80=99s =E2=80=98Revision History=E2=80=99 section? =C2=
=A0</div></div></blockquote><div><br>As someone that has strongly argued ag=
ainst current() on grounds of performance, elegance and correctness,=C2=A0 =
I'm very happy that the authors made this change. <br></div><br>Now, as=
per documentation, an execution context has pointer semantics represent a =
reference to a *suspended* execution context (and empty otherwise) [1]. As =
the current context can't be possibly suspended, there is no possible m=
eaning for the current() function.=C2=A0 There is also no need for it, as y=
ou can't do anything with the current context. To switch to another con=
text you just need a pointer to that context; how you get it is up to the a=
pplication.<br></div></blockquote><div><br><br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">I'm also happy that the authors=
added support for 'yield with current continuation' in the form of=
operator()(std::invoke_ontop_<wbr>arg,...). This, in addition to being a p=
owerful context composition operator allow seamless inter-operation with st=
d::future without any compiler support (i.e. await can be a normal function=
instead of a language keyword).<br></div></blockquote><div><br>... I fail =
to see how that has anything to do with `co_await` or `future`.<br><br>`co_=
await` is primarily about halting the current function, generating a promis=
e object to represent the eventual return value, returning a "future&q=
uot; object, and scheduling the continuation of the current function based =
on the result of an expression that has been passed to you.<br><br></div></=
div></blockquote><div><br>Co-await is about making async heavy code more sa=
ne. It is limited to only suspending a single stack frame and always yieldi=
ng to the calling function, but these are not desirable properties and are =
just an artefact of the specific compilation strategy it is designed for.<b=
r>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>Switching contexts doesn't halt just the current function; it hal=
ts the entire context. </div></div></blockquote><div><br>That is, it contex=
t can suspend N nested function frames. For N=3D1 it reduces to the await s=
cenario.<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>The only way those two can be the same thing is if the call=
er called the function as a separate execution context. And like 95% of the=
point of `co_await` is that the caller of such a continuation <i>doesn'=
;t have to know</i> that it's doing continuation stuff. It calls it jus=
t like a regular function.</div>Now
personally, I don't care much for `co_await`. I much prefer=20
context-based switching, and `co_await` is really terrible at handling=20
anything more complex than a single function. But you can't deny that=
=20
the language feature requires much less explicit work from the user.</div><=
/blockquote><div><br>it is easy to write a wrapper function that allows usi=
ng the exact same syntax as the builtin await (except that await becomes a =
function object instead of a keyword). The standard should provide it and i=
t wouldn't require any more explicit work for the user than a builtin a=
wait.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b0d5b54d-0f55-4f3a-bbcf-de1e4ef90eb4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0d5b54d-0f55-4f3a-bbcf-de1e4ef90eb4=
%40isocpp.org</a>.<br />
------=_Part_1005_663117309.1480727181403--
------=_Part_1004_1040038033.1480727181402--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 2 Dec 2016 22:01:14 -0800 (PST)
Raw View
------=_Part_950_2055330321.1480744874673
Content-Type: multipart/alternative;
boundary="----=_Part_951_1426821451.1480744874673"
------=_Part_951_1426821451.1480744874673
Content-Type: text/plain; charset=UTF-8
On Friday, December 2, 2016 at 8:06:21 PM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Friday, December 2, 2016 at 5:07:38 PM UTC, Nicol Bolas wrote:
>>
>> On Friday, December 2, 2016 at 7:38:02 AM UTC-5, Giovanni Piero Deretta
>> wrote:
>>>
>>> On Monday, November 28, 2016 at 11:35:01 PM UTC, Bryce Glover wrote:
>>>
>> I'm also happy that the authors added support for 'yield with current
>>> continuation' in the form of operator()(std::invoke_ontop_arg,...). This,
>>> in addition to being a powerful context composition operator allow seamless
>>> inter-operation with std::future without any compiler support (i.e. await
>>> can be a normal function instead of a language keyword).
>>>
>>
>> ... I fail to see how that has anything to do with `co_await` or `future`.
>>
>> `co_await` is primarily about halting the current function, generating a
>> promise object to represent the eventual return value, returning a "future"
>> object, and scheduling the continuation of the current function based on
>> the result of an expression that has been passed to you.
>>
>
> Co-await is about making async heavy code more sane. It is limited to only
> suspending a single stack frame and always yielding to the calling
> function, but these are not desirable properties and are just an artefact
> of the specific compilation strategy it is designed for.
>
Whether they are desirable properties is neither here nor there. My point
is that the principle use case of `co_await` is not one that
`execution_context` can service *without* a great deal of manual work on
the user's end. And this is not work that can be shoved off into some
library.
Specifically, I don't see how `std::invoke_ontop_arg` in any way helps
`execution_context` behave like `co_await`. As I understand it, that
functionality permits resuming a context to not actually continue
execution; instead, it calls some other function which will go off and do
something.
>
>> Switching contexts doesn't halt just the current function; it halts the
>> entire context.
>>
>
> That is, it context can suspend N nested function frames. For N=1 it
> reduces to the await scenario.
>
>
>> The only way those two can be the same thing is if the caller called the
>> function as a separate execution context. And like 95% of the point of
>> `co_await` is that the caller of such a continuation *doesn't have to
>> know* that it's doing continuation stuff. It calls it just like a
>> regular function.
>> Now personally, I don't care much for `co_await`. I much prefer
>> context-based switching, and `co_await` is really terrible at handling
>> anything more complex than a single function. But you can't deny that the
>> language feature requires much less explicit work from the user.
>>
>
> it is easy to write a wrapper function that allows using the exact same
> syntax as the builtin await (except that await becomes a function object
> instead of a keyword). The standard should provide it and it wouldn't
> require any more explicit work for the user than a builtin await.
>
Alright, so let's see what that would look like.
First, let's set the parameters for the example. `co_await` has a lot of
functionality; way too much, if you ask me. It has a lot of machinery for
doing things it has no business doing like generators, that Godawful
"do-notation" or whatever. So instead, let us focus on the primary use case
that `co_await` was designed for. That situation is as follows:
There is some asynchronous process P. It will produce some value T.
>
> There is a Function B which will launch process P. It will receive this
> value and do some processing work, returning the result. In order to keep
> people from having to wait on the result, Function B can schedule its
> continuation based on P. That is, if P has already completed, then the rest
> of B *will happen immediately*. It will receive T, do the processing, and
> return a result to the caller. If P is not ready yet, then B's execution
> will be scheduled based on some mechanism that P provides for automatically
> scheduling continuations after the completion of its processing. Control
> will thus be transferred back to the caller, but no true return value will
> be returned.
>
> There is also a Function A which calls Function B. Because B's execution
> may not be immediate, B's actual return value is an object that represents
> a value which may be provided later (aka: a future). Of course, this also
> means that B will have the other half of that communication channel which
> provides that value (aka: a promise), just in case B actually executes
> asynchronously.
>
With `co_await`, this code looks like this:
std::future<Q> FunctionB()
{
co_return PlayWithT(co_await ProcessP());
}
void FunctionA()
{
auto ftr = FunctionB();
while(ftr.wait_for(0) != std::future_status::ready)
//Do something else.
auto value = ftr.get();
//Use `value`.
}
I would like to see what you envision the `execution_context`-based version
of this code to look like. Feel free to invent whatever objects you would
like to in order to make it work. I don't particularly need to see a full
implementation of them, but a description of what those objects do would be
nice. My main point is to see what day-to-day use of these mechanisms would
look like.
There are two things I'm curious about in the `execution_context` version.
First, how do you keep `FunctionA` from having to explicitly use an
`execution_context` when calling `FunctionB`? Do you have to create some
intermediate `FunctionB2` that calls `FunctionB`, while storing the promise
and execution_context? Or do you implement `FunctionB` by putting the
business logic of B in some lambda, effectively doing the same as the
intermediate function?
Second, I want to see how you handle the two cases I suggested before, with
regard to `ProcessP`. That is, if `ProcessP` has already completed, how do
you *avoid* doing a context switch in scheduling the continuation of
`FunctionB`?
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2bc7b31-2038-4a51-b9eb-8eb6076339e4%40isocpp.org.
------=_Part_951_1426821451.1480744874673
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, December 2, 2016 at 8:06:21 PM UTC-5, Giovanni =
Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Friday, December 2, 2016 at 5:07:38 PM UTC, Nicol Bolas 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">On Friday, December=
2, 2016 at 7:38:02 AM UTC-5, Giovanni Piero Deretta wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">On Monday, November 28, 2016 at 11=
:35:01 PM UTC, Bryce Glover wrote:</div></blockquote><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">I'm also happy that the authors adde=
d support for 'yield with current continuation' in the form of oper=
ator()(std::invoke_ontop_<wbr>arg,...). This, in addition to being a powerf=
ul context composition operator allow seamless inter-operation with std::fu=
ture without any compiler support (i.e. await can be a normal function inst=
ead of a language keyword).<br></div></blockquote><div><br>... I fail to se=
e how that has anything to do with `co_await` or `future`.<br><br>`co_await=
` is primarily about halting the current function, generating a promise obj=
ect to represent the eventual return value, returning a "future" =
object, and scheduling the continuation of the current function based on th=
e result of an expression that has been passed to you.<br></div></div></blo=
ckquote><div><br>Co-await is about making async heavy code more sane. It is=
limited to only suspending a single stack frame and always yielding to the=
calling function, but these are not desirable properties and are just an a=
rtefact of the specific compilation strategy it is designed for.<br></div><=
/div></blockquote><div><br>Whether they are desirable properties is neither=
here nor there. My point is that the principle use case of `co_await` is n=
ot one that `execution_context` can service <i>without</i> a great deal of =
manual work on the user's end. And this is not work that can be shoved =
off into some library.<br><br>Specifically, I don't see how `std::invok=
e_ontop_arg` in any way helps `execution_context` behave like `co_await`. A=
s I understand it, that functionality permits resuming a context to not act=
ually continue execution; instead, it calls some other function which will =
go off and do something.<br><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><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"><div>Switching contexts doesn't halt just the c=
urrent function; it halts the entire context. </div></div></blockquote><div=
><br>That is, it context can suspend N nested function frames. For N=3D1 it=
reduces to the await scenario.<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div>The only way those two can be the same th=
ing is if the caller called the function as a separate execution context. A=
nd like 95% of the point of `co_await` is that the caller of such a continu=
ation <i>doesn't have to know</i> that it's doing continuation stuf=
f. It calls it just like a regular function.</div>Now
personally, I don't care much for `co_await`. I much prefer=20
context-based switching, and `co_await` is really terrible at handling=20
anything more complex than a single function. But you can't deny that=
=20
the language feature requires much less explicit work from the user.</div><=
/blockquote><div><br>it is easy to write a wrapper function that allows usi=
ng the exact same syntax as the builtin await (except that await becomes a =
function object instead of a keyword). The standard should provide it and i=
t wouldn't require any more explicit work for the user than a builtin a=
wait.<br></div></div></blockquote><div><br>Alright, so let's see what t=
hat would look like.<br><br>First, let's set the parameters for the exa=
mple. `co_await` has a lot of functionality; way too much, if you ask me. I=
t has a lot of machinery for doing things it has no business doing like gen=
erators, that Godawful "do-notation" or whatever. So instead, let=
us focus on the primary use case that `co_await` was designed for. That si=
tuation is as follows:<br><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;">There is some asynchronous process P. It will produce some val=
ue T.<br><br>There is a Function B which will launch process P. It will rec=
eive this value and do some processing work, returning the result. In order=
to keep people from having to wait on the result, Function B can schedule =
its continuation based on P. That is, if P has already completed, then the =
rest of B <i>will happen immediately</i>. It will receive T, do the process=
ing, and return a result to the caller. If P is not ready yet, then B's=
execution will be scheduled based on some mechanism that P provides for au=
tomatically scheduling continuations after the completion of its processing=
.. Control will thus be transferred back to the caller, but no true return v=
alue will be returned.<br><br>There is also a Function A which calls Functi=
on B. Because B's execution may not be immediate, B's actual return=
value is an object that represents a value which may be provided later (ak=
a: a future). Of course, this also means that B will have the other half of=
that communication channel which provides that value (aka: a promise), jus=
t in case B actually executes asynchronously.<br></blockquote><br>With `co_=
await`, this code looks like this:<br><br><div style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">future</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">Q</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">FunctionB</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></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: #000=
;" class=3D"styled-by-prettify">=C2=A0 co_return </span><code class=3D"pret=
typrint"><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">PlayWithT</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><code class=
=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
co_await </span><span style=3D"color: #606;" class=3D"styled-by-prettify">P=
rocessP</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></co=
de><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></code><spa=
n 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;" clas=
s=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">FunctionA</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> ftr </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">FunctionB</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">while</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">ftr</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">w=
ait_for</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><spa=
n 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-by-prettify">!=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">future_status</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">ready</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</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-pre=
ttify">//Do something else.</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> value </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> ftr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">get</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span sty=
le=3D"color: #800;" class=3D"styled-by-prettify">//Use `value`.</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>I would like to see what you envision the `execution_context`-based vers=
ion of this code to look like. Feel free to invent whatever objects you wou=
ld like to in order to make it work. I don't particularly need to see a=
full implementation of them, but a description of what those objects do wo=
uld be nice. My main point is to see what day-to-day use of these mechanism=
s would look like.<br><br>There are two things I'm curious about in the=
`execution_context` version.<br><br>First, how do you keep `FunctionA` fro=
m having to explicitly use an `execution_context` when calling `FunctionB`?=
Do you have to create some intermediate `FunctionB2` that calls `FunctionB=
`, while storing the promise and execution_context? Or do you implement `Fu=
nctionB` by putting the business logic of B in some lambda, effectively doi=
ng the same as the intermediate function?<br><br>Second, I want to see how =
you handle the two cases I suggested before, with regard to `ProcessP`. Tha=
t is, if `ProcessP` has already completed, how do you <i>avoid</i> doing a =
context switch in scheduling the continuation of `FunctionB`?<br></div></di=
v>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f2bc7b31-2038-4a51-b9eb-8eb6076339e4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f2bc7b31-2038-4a51-b9eb-8eb6076339e4=
%40isocpp.org</a>.<br />
------=_Part_951_1426821451.1480744874673--
------=_Part_950_2055330321.1480744874673--
.
Author: Oliver Kowalke <oliver.kowalke@gmail.com>
Date: Sat, 3 Dec 2016 10:02:40 +0100
Raw View
--001a113f6de85272960542bd525c
Content-Type: text/plain; charset=UTF-8
2016-12-03 2:06 GMT+01:00 Giovanni Piero Deretta <gpderetta@gmail.com>:
> it is easy to write a wrapper function that allows using the exact same
> syntax as the builtin await (except that await becomes a function object
> instead of a keyword)
>
Evgeny Panasyuk has written such a wrapper -
https://github.com/evgeny-panasyuk/await_emu
(it is based on boost.coroutine but execution_context is used as base
building block for boost.coroutine)
for(auto &&f : fs) {
cout << await f << ":\tafter end" << endl;
}
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18YpuP0Lr5GCnCqFY4YNo0P2hUKQhtsQfAwbA%3DyVWv1%2BA%40mail.gmail.com.
--001a113f6de85272960542bd525c
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=
-12-03 2:06 GMT+01:00 Giovanni Piero Deretta <span dir=3D"ltr"><<a href=
=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@gmail.com</a>&g=
t;</span>:<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"><span class=3D"gmail-"></span>it is easy to write a wrapper function =
that allows using the exact same syntax as the builtin await (except that a=
wait becomes a function object instead of a keyword) </div></blockquote><di=
v><span class=3D"gmail-author"></span><br>Evgeny Panasyuk has written such =
a wrapper -<a href=3D"https://github.com/evgeny-panasyuk/await_emu">https:/=
/github.com/evgeny-panasyuk/await_emu</a><br></div><div>(it is based on boo=
st.coroutine but execution_context is used as base building block for boost=
..coroutine)<br><br><pre><span class=3D"gmail-pl-k">for</span>(<span class=
=3D"gmail-pl-k">auto</span> &&f : fs) {
cout << await f << <span class=3D"gmail-pl-s"><span class=
=3D"gmail-pl-pds">"</span>:<span class=3D"gmail-pl-cce">\t</span>after=
end<span class=3D"gmail-pl-pds">"</span></span> << endl;<br>}<b=
r></pre><br></div></div><br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18YpuP0Lr5GCnCqFY4YNo0P2hUKQh=
tsQfAwbA%3DyVWv1%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18Y=
puP0Lr5GCnCqFY4YNo0P2hUKQhtsQfAwbA%3DyVWv1%2BA%40mail.gmail.com</a>.<br />
--001a113f6de85272960542bd525c--
.
Author: Oliver Kowalke <oliver.kowalke@gmail.com>
Date: Sat, 3 Dec 2016 10:12:30 +0100
Raw View
--001a11448a3276c1db0542bd7560
Content-Type: text/plain; charset=UTF-8
2016-12-03 7:01 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> With `co_await`, this code looks like this:
>>>
>>> std::future<Q> FunctionB()
>>> {
>>> co_return PlayWithT(co_await ProcessP());
>>> }
>>>
>>> void FunctionA()
>>> {
>>> auto ftr = FunctionB();
>>> while(ftr.wait_for(0) != std::future_status::ready)
>>> //Do something else.
>>> auto value = ftr.get();
>>> //Use `value`.
>>> }
>>>
>>> I would like to see what you envision the `execution_context`-based
>>> version of this code to look like. Feel free to invent whatever objects you
>>> would like to in order to make it work. I don't particularly need to see a
>>> full implementation of them, but a description of what those objects do
>>> would be nice. My main point is to see what day-to-day use of these
>>> mechanisms would look like.
>>>
>>
I paste Evgeny's example from await_emu (https://github.com/evgeny-
panasyuk/await_emu):
int bar(int i){
// await is not limited by "one level" as in C#
auto result = await async([i]{ return reschedule(), i*100; });
return result + i*10;
}
int foo(int i){
cout << i << ":\tbegin" << endl;
cout << await async([i]{ return reschedule(), i*10; }) << ":\tbody" << endl;
cout << bar(i) << ":\tend" << endl;
return i*1000;
}
void async_user_handler(){
vector<future<int>> fs;
// instead of `async` at function signature, `asynchronous` should be
// used at the call place:
for(auto i=0; i!=5; ++i) {
fs.push_back( asynchronous([i]{ return foo(i+1); }) );
}
for(auto &&f : fs) {
cout << await f << ":\tafter end" << endl;
}
}
output:
1: begin
2: begin
3: begin
4: begin
5: begin
20: body
10: body
30: body
110: end
1000: after end
50: body
220: end
2000: after end
550: end
40: body
330: end
3000: after end
440: end
4000: after end
5000: after end
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_ywacgNVD5m%2B0-rHZptUuOG0JE5peG7xdky4sv99M%2BpQ%40mail.gmail.com.
--001a11448a3276c1db0542bd7560
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2016-12-03 7:01 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:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gm=
ail-"></span><span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873=
149760578gmail-"><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"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>With `co_aw=
ait`, this code looks like this:<br><br><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail=
-m_132935932795361199prettyprint"><code class=3D"gmail-m_-83729234890048139=
14gmail-m_-6575460873149760578gmail-m_132935932795361199prettyprint"><div c=
lass=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_132=
935932795361199subprettyprint"><span style=3D"color:rgb(0,0,0)" class=3D"gm=
ail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_1329359327953=
61199styled-by-prettify">std</span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_13293=
5932795361199styled-by-prettify">::</span><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_13=
2935932795361199styled-by-prettify">future</span><span style=3D"color:rgb(1=
02,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-657546087314976057=
8gmail-m_132935932795361199styled-by-prettify"><</span><span style=3D"co=
lor:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149=
760578gmail-m_132935932795361199styled-by-prettify">Q</span><span style=3D"=
color:rgb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460=
873149760578gmail-m_132935932795361199styled-by-prettify">></span><span =
style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-65=
75460873149760578gmail-m_132935932795361199styled-by-prettify"> </span><spa=
n style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-8372923489004813914gmail=
-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettify">Functi=
onB</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-8372923489=
004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-pr=
ettify">()</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923=
489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by=
-prettify"><br></span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m=
_-8372923489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199=
styled-by-prettify">{</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail=
-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_1329359327953611=
99styled-by-prettify"><br></span><span style=3D"color:rgb(0,0,0)" class=3D"=
gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_13293593279=
5361199styled-by-prettify">=C2=A0 co_return </span><code class=3D"gmail-m_-=
8372923489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199pr=
ettyprint"><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923489004=
813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prett=
ify"></span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-83729234=
89004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-=
prettify">PlayWithT</span><span style=3D"color:rgb(102,102,0)" class=3D"gma=
il-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_13293593279536=
1199styled-by-prettify">(</span><code class=3D"gmail-m_-8372923489004813914=
gmail-m_-6575460873149760578gmail-m_132935932795361199prettyprint"><span st=
yle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575=
460873149760578gmail-m_132935932795361199styled-by-prettify">co_await </spa=
n><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-837292348900481391=
4gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettify">=
ProcessP</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-83729=
23489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-=
by-prettify">()</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m=
_-8372923489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199=
styled-by-prettify"></span></code><span style=3D"color:rgb(102,102,0)" clas=
s=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_132935=
932795361199styled-by-prettify">);</span><span style=3D"color:rgb(0,0,0)" c=
lass=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_132=
935932795361199styled-by-prettify"><br></span></code><span style=3D"color:r=
gb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-65754608731497=
60578gmail-m_132935932795361199styled-by-prettify"></span><span style=3D"co=
lor:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149=
760578gmail-m_132935932795361199styled-by-prettify"></span><span style=3D"c=
olor:rgb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-65754608=
73149760578gmail-m_132935932795361199styled-by-prettify">}</span><span styl=
e=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-657546=
0873149760578gmail-m_132935932795361199styled-by-prettify"><br><br></span><=
span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-8372923489004813914gmai=
l-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettify">void<=
/span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-837292348900481391=
4gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettify">=
</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-837292348900=
4813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-pret=
tify">FunctionA</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m=
_-8372923489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199=
styled-by-prettify">()</span><span style=3D"color:rgb(0,0,0)" class=3D"gmai=
l-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_132935932795361=
199styled-by-prettify"><br></span><span style=3D"color:rgb(102,102,0)" clas=
s=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_132935=
932795361199styled-by-prettify">{</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_1329=
35932795361199styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:rg=
b(0,0,136)" class=3D"gmail-m_-8372923489004813914gmail-m_-65754608731497605=
78gmail-m_132935932795361199styled-by-prettify">auto</span><span style=3D"c=
olor:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-657546087314=
9760578gmail-m_132935932795361199styled-by-prettify"> ftr </span><span styl=
e=3D"color:rgb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-65=
75460873149760578gmail-m_132935932795361199styled-by-prettify">=3D</span><s=
pan style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m=
_-6575460873149760578gmail-m_132935932795361199styled-by-prettify"> </span>=
<span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-8372923489004813914g=
mail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettify">Fu=
nctionB</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-837292=
3489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-b=
y-prettify">();</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-83=
72923489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styl=
ed-by-prettify"><br>=C2=A0 </span><span style=3D"color:rgb(0,0,136)" class=
=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_1329359=
32795361199styled-by-prettify">while</span><span style=3D"color:rgb(102,102=
,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail=
-m_132935932795361199styled-by-prettify">(</span><span style=3D"color:rgb(0=
,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gma=
il-m_132935932795361199styled-by-prettify">ftr</span><span style=3D"color:r=
gb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-65754608731497=
60578gmail-m_132935932795361199styled-by-prettify">.</span><span style=3D"c=
olor:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-657546087314=
9760578gmail-m_132935932795361199styled-by-prettify">wait_for</span><span s=
tyle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_=
-6575460873149760578gmail-m_132935932795361199styled-by-prettify">(</span><=
span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-8372923489004813914gm=
ail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettify">0</=
span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-837292348900481=
3914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettif=
y">)</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923489004=
813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prett=
ify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-8372923=
489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by=
-prettify">!=3D</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-83=
72923489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styl=
ed-by-prettify"> std</span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_1329359327953=
61199styled-by-prettify">::</span><span style=3D"color:rgb(0,0,0)" class=3D=
"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_1329359327=
95361199styled-by-prettify">future_status</span><span style=3D"color:rgb(10=
2,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578=
gmail-m_132935932795361199styled-by-prettify">::</span><span style=3D"color=
:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760=
578gmail-m_132935932795361199styled-by-prettify">ready</span><span style=3D=
"color:rgb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-657546=
0873149760578gmail-m_132935932795361199styled-by-prettify">)</span><span st=
yle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575=
460873149760578gmail-m_132935932795361199styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color:rgb(136,0,0)" class=3D"gmail-m_-83729234890=
04813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-pre=
ttify">//Do something else.</span><span style=3D"color:rgb(0,0,0)" class=3D=
"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_1329359327=
95361199styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:rgb(0,0,=
136)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmai=
l-m_132935932795361199styled-by-prettify">auto</span><span style=3D"color:r=
gb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-657546087314976057=
8gmail-m_132935932795361199styled-by-prettify"> value </span><span style=3D=
"color:rgb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-657546=
0873149760578gmail-m_132935932795361199styled-by-prettify">=3D</span><span =
style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-65=
75460873149760578gmail-m_132935932795361199styled-by-prettify"> ftr</span><=
span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-8372923489004813914gm=
ail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettify">.</=
span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-83729234890048139=
14gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-prettify"=
>get</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-837292348=
9004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-by-p=
rettify">();</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-83729=
23489004813914gmail-m_-6575460873149760578gmail-m_132935932795361199styled-=
by-prettify"><br>=C2=A0 </span><span style=3D"color:rgb(136,0,0)" class=3D"=
gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-m_13293593279=
5361199styled-by-prettify">//Use `value`.</span><span style=3D"color:rgb(0,=
0,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmai=
l-m_132935932795361199styled-by-prettify"><br></span><span style=3D"color:r=
gb(102,102,0)" class=3D"gmail-m_-8372923489004813914gmail-m_-65754608731497=
60578gmail-m_132935932795361199styled-by-prettify">}</span></div></code></d=
iv><br>I would like to see what you envision the `execution_context`-based =
version of this code to look like. Feel free to invent whatever objects you=
would like to in order to make it work. I don't particularly need to s=
ee a full implementation of them, but a description of what those objects d=
o would be nice. My main point is to see what day-to-day use of these mecha=
nisms would look like.<br></div></blockquote></div></blockquote></span></di=
v></blockquote></div><br></div><div class=3D"gmail_extra">I paste Evgeny=
9;s example from await_emu (<a href=3D"https://github.com/evgeny-panasyuk/a=
wait_emu" target=3D"_blank">https://github.com/evgeny-<wbr>panasyuk/await_e=
mu</a>):<br></div><div class=3D"gmail_extra"><pre><span class=3D"gmail-m_-8=
372923489004813914gmail-m_-6575460873149760578gmail-pl-k">int</span> <span =
class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-pl-e=
n">bar</span>(<span class=3D"gmail-m_-8372923489004813914gmail-m_-657546087=
3149760578gmail-pl-k">int</span> i){
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578=
gmail-pl-c">// await is not limited by "one level" as in C#</span=
>
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578=
gmail-pl-k">auto</span> result =3D await <span class=3D"gmail-m_-8372923489=
004813914gmail-m_-6575460873149760578gmail-pl-smi">async</span>([i]{ <span =
class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-pl-k=
">return</span> <span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460=
873149760578gmail-pl-c1">reschedule</span>(), i*<span class=3D"gmail-m_-837=
2923489004813914gmail-m_-6575460873149760578gmail-pl-c1">100</span>; });
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578=
gmail-pl-k">return</span> result + i*<span class=3D"gmail-m_-83729234890048=
13914gmail-m_-6575460873149760578gmail-pl-c1">10</span>;
}
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmai=
l-pl-k">int</span> <span class=3D"gmail-m_-8372923489004813914gmail-m_-6575=
460873149760578gmail-pl-en">foo</span>(<span class=3D"gmail-m_-837292348900=
4813914gmail-m_-6575460873149760578gmail-pl-k">int</span> i){
cout << i << <span class=3D"gmail-m_-8372923489004813914gma=
il-m_-6575460873149760578gmail-pl-s"><span class=3D"gmail-m_-83729234890048=
13914gmail-m_-6575460873149760578gmail-pl-pds">"</span>:<span class=3D=
"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-pl-cce">\t</=
span>begin<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149=
760578gmail-pl-pds">"</span></span> << endl;
cout << await <span class=3D"gmail-m_-8372923489004813914gmail-m_=
-6575460873149760578gmail-pl-smi">async</span>([i]{ <span class=3D"gmail-m_=
-8372923489004813914gmail-m_-6575460873149760578gmail-pl-k">return</span> <=
span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail=
-pl-c1">reschedule</span>(), i*<span class=3D"gmail-m_-8372923489004813914g=
mail-m_-6575460873149760578gmail-pl-c1">10</span>; }) << <span class=
=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-pl-s"><sp=
an class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-p=
l-pds">"</span>:<span class=3D"gmail-m_-8372923489004813914gmail-m_-65=
75460873149760578gmail-pl-cce">\t</span>body<span class=3D"gmail-m_-8372923=
489004813914gmail-m_-6575460873149760578gmail-pl-pds">"</span></span> =
<< endl;
cout << <span class=3D"gmail-m_-8372923489004813914gmail-m_-65754=
60873149760578gmail-pl-c1">bar</span>(i) << <span class=3D"gmail-m_-8=
372923489004813914gmail-m_-6575460873149760578gmail-pl-s"><span class=3D"gm=
ail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-pl-pds">"<=
/span>:<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760=
578gmail-pl-cce">\t</span>end<span class=3D"gmail-m_-8372923489004813914gma=
il-m_-6575460873149760578gmail-pl-pds">"</span></span> << endl;
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578=
gmail-pl-k">return</span> i*<span class=3D"gmail-m_-8372923489004813914gmai=
l-m_-6575460873149760578gmail-pl-c1">1000</span>;
}
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmai=
l-pl-k">void</span> <span class=3D"gmail-m_-8372923489004813914gmail-m_-657=
5460873149760578gmail-pl-en">async_user_handler</span>(){
vector<future<<span class=3D"gmail-m_-8372923489004813914gmail-m_=
-6575460873149760578gmail-pl-k">int</span>>> fs;
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578=
gmail-pl-c">// instead of `async` at function signature, `asynchronous` sho=
uld be</span>
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578=
gmail-pl-c">// used at the call place:</span>
<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578=
gmail-pl-k">for</span>(<span class=3D"gmail-m_-8372923489004813914gmail-m_-=
6575460873149760578gmail-pl-k">auto</span> i=3D<span class=3D"gmail-m_-8372=
923489004813914gmail-m_-6575460873149760578gmail-pl-c1">0</span>; i!=3D<spa=
n class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-pl=
-c1">5</span>; ++i) {
fs.<span class=3D"gmail-m_-8372923489004813914gmail-m_-657546087314=
9760578gmail-pl-c1">push_back</span>( <span class=3D"gmail-m_-8372923489004=
813914gmail-m_-6575460873149760578gmail-pl-c1">asynchronous</span>([i]{ <sp=
an class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-p=
l-k">return</span> <span class=3D"gmail-m_-8372923489004813914gmail-m_-6575=
460873149760578gmail-pl-c1">foo</span>(i+<span class=3D"gmail-m_-8372923489=
004813914gmail-m_-6575460873149760578gmail-pl-c1">1</span>); }) );<br> }=
<br> =C2=A0<span class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873=
149760578gmail-pl-k">for</span>(<span class=3D"gmail-m_-8372923489004813914=
gmail-m_-6575460873149760578gmail-pl-k">auto</span> &&f : fs) {
cout << await f << <span class=3D"gmail-m_-837292348900=
4813914gmail-m_-6575460873149760578gmail-pl-s"><span class=3D"gmail-m_-8372=
923489004813914gmail-m_-6575460873149760578gmail-pl-pds">"</span>:<spa=
n class=3D"gmail-m_-8372923489004813914gmail-m_-6575460873149760578gmail-pl=
-cce">\t</span>after end<span class=3D"gmail-m_-8372923489004813914gmail-m_=
-6575460873149760578gmail-pl-pds">"</span></span> << endl;<br> =
}<br>}</pre>output:<br><pre><code>1: begin
2: begin
3: begin
4: begin
5: begin
20: body
10: body
30: body
110: end
1000: after end
50: body
220: end
2000: after end
550: end
40: body
330: end
3000: after end
440: end
4000: after end
5000: after end
</code></pre><br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_ywacgNVD5m%2B0-rHZptUuOG0JE=
5peG7xdky4sv99M%2BpQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_y=
wacgNVD5m%2B0-rHZptUuOG0JE5peG7xdky4sv99M%2BpQ%40mail.gmail.com</a>.<br />
--001a11448a3276c1db0542bd7560--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 3 Dec 2016 09:09:23 -0800 (PST)
Raw View
------=_Part_1029_1160348016.1480784963941
Content-Type: multipart/alternative;
boundary="----=_Part_1030_997199456.1480784963942"
------=_Part_1030_997199456.1480784963942
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, December 3, 2016 at 4:12:52 AM UTC-5, Oliver Kowalke wrote:
>
> 2016-12-03 7:01 GMT+01:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> With `co_await`, this code looks like this:
>>>>
>>>> std::future<Q> FunctionB()
>>>> {
>>>> co_return PlayWithT(co_await ProcessP());
>>>> }
>>>>
>>>> void FunctionA()
>>>> {
>>>> auto ftr =3D FunctionB();
>>>> while(ftr.wait_for(0) !=3D std::future_status::ready)
>>>> //Do something else.
>>>> auto value =3D ftr.get();
>>>> //Use `value`.
>>>> }
>>>>
>>>> I would like to see what you envision the `execution_context`-based=20
>>>> version of this code to look like. Feel free to invent whatever object=
s you=20
>>>> would like to in order to make it work. I don't particularly need to s=
ee a=20
>>>> full implementation of them, but a description of what those objects d=
o=20
>>>> would be nice. My main point is to see what day-to-day use of these=20
>>>> mechanisms would look like.
>>>>
>>>
> I paste Evgeny's example from await_emu (
> https://github.com/evgeny-panasyuk/await_emu):
>
That's a nice library and interesting examples, but I'm afraid that it=20
doesn't really address my point. I specifically called out two things I=20
wanted such code to demonstrate: how to call such functions without the=20
suspension of those functions causing the caller to suspend too, and how it=
=20
would avoid a context switch if the async process had already finished. The=
=20
examples you've posted do not describe either.
For point 1, the comment "await is not limited by "one level" as in C#"=20
seems to strongly suggest that suspending the function will not suspend=20
*just* that function. It will suspend the entire call stack. So, how do you=
=20
call, for example `bar`, in a way that doesn't suspend yourself if `bar`=20
needs to suspend itself? I suspect it would look something like this:
auto task =3D std::packaged_task<int(int)>(bar);
execution_context<whatever> ec(task);
auto ftr =3D task.get_future();
ec(integer);
I'm sure you could wrap this in some kind of object. A=20
`context_task<int(int)>`, which represents the ability to start and resume=
=20
a function that returns a value via promise/future, but that function gets=
=20
executed in a context.
But `co_await` doesn't need to do that. It creates this machinery behind=20
the scenes. And that's the whole point of `co_await`: you don't have to=20
create the machinery yourself.
The caller of a function doesn't have to do something different to call a=
=20
function that uses `co_await`. They call it, just like any other function.=
=20
They interact with its return value as being exactly that function's return=
=20
value (usually a future of some form). And if they want to `co_await` on=20
that return value, to suspend themselves until it completes, they can do=20
so. But they do not *have to*.
So I submit that this library, while clever, does not actually implement=20
`co_await`. It merely emulates syntax *similar* to `co_await`. But its=20
behavior of this syntax is quite different, and fundamentally so.
I do not intend for these questions to be an attack on `execution_context`.=
=20
I have never doubted the inherent utility of `execution_context` as a=20
generalized coroutine mechanism. I have never doubted its ability to be=20
used as the basis of incredibly useful and powerful higher level=20
constructs. And I think it's almost criminal that it didn't make it into=20
C++17.
However, after reading P0444, I have noticed a trend among the people who=
=20
want an alternative to `co_await`. That trend being... they frequently=20
misunderstand exactly what `co_await` is doing. They'll often describe it=
=20
as "up-and-out" or "suspend-by-return" or some-such.
In particular, P0444 describes "suspend-by-return" with "In particular,=20
when a function suspends, its caller must also suspend, and so must its=20
caller=E2=80=99s caller, and so forth." That's not true at all. The caller =
only=20
suspends if the caller *wants to* suspend. It can choose instead to do=20
something else if the value isn't ready. It can choose to store that future=
=20
in an array of futures, that someone else will iterate over. And so forth.=
=20
The important point being that the caller *gets to decide* if they want to=
=20
take part in the continuation or go do something else.
What I doubt is that you can build an equivalent to `co_await` that can be=
=20
as transparent as `co_await` ultimately is. Pretty much every example=20
requires the caller to invoke such functions in a special way, based on=20
whether or not it is a continuation function or not.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fbb60521-431e-4f46-bdf7-64f0cd5f85c9%40isocpp.or=
g.
------=_Part_1030_997199456.1480784963942
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 3, 2016 at 4:12:52 AM UTC-5, Oliver =
Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">2016-12-03 7:01 GMT+01:00 Nicol Bolas <spa=
n dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"9fQkbqtZBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">jmck...@gmail.com</a>></span>:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><span></span><span><blockquote cl=
ass=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"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div>With `co_await`, this code looks like this=
:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px"><code><div><span style=3D"=
color:rgb(0,0,0)">std</span><span style=3D"color:rgb(102,102,0)">::</span><=
span style=3D"color:rgb(0,0,0)">future</span><span style=3D"color:rgb(102,1=
02,0)"><</span><span style=3D"color:rgb(0,0,0)">Q</span><span style=3D"c=
olor:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(102,0,102)">FunctionB</span><span style=3D"color:rgb=
(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"><br></span><span sty=
le=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br></=
span><span style=3D"color:rgb(0,0,0)">=C2=A0 co_return </span><code><span s=
tyle=3D"color:rgb(0,0,0)"></span><span style=3D"color:rgb(102,0,102)">PlayW=
ithT</span><span style=3D"color:rgb(102,102,0)">(</span><code><span style=
=3D"color:rgb(0,0,0)">co_await </span><span style=3D"color:rgb(102,0,102)">=
ProcessP</span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D=
"color:rgb(102,102,0)"></span></code><span style=3D"color:rgb(102,102,0)">)=
;</span><span style=3D"color:rgb(0,0,0)"><br></span></code><span style=3D"c=
olor:rgb(102,102,0)"></span><span style=3D"color:rgb(0,0,0)"></span><span s=
tyle=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rgb(0,0,0)"><br>=
<br></span><span style=3D"color:rgb(0,0,136)">void</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">FunctionA</span=
><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0=
,0)"><br></span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D=
"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rgb(0,0,136)">aut=
o</span><span style=3D"color:rgb(0,0,0)"> ftr </span><span style=3D"color:r=
gb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span sty=
le=3D"color:rgb(102,0,102)">FunctionB</span><span style=3D"color:rgb(102,10=
2,0)">();</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span st=
yle=3D"color:rgb(0,0,136)">while</span><span style=3D"color:rgb(102,102,0)"=
>(</span><span style=3D"color:rgb(0,0,0)">ftr</span><span style=3D"color:rg=
b(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">wait_for</span><span=
style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,102,102)=
">0</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color=
:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">!=3D</span><span =
style=3D"color:rgb(0,0,0)"> std</span><span style=3D"color:rgb(102,102,0)">=
::</span><span style=3D"color:rgb(0,0,0)">future_status</span><span style=
=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">ready</=
span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(=
0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">//Do so=
mething else.</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><spa=
n style=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(0,0,0)">=
value </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D=
"color:rgb(0,0,0)"> ftr</span><span style=3D"color:rgb(102,102,0)">.</span>=
<span style=3D"color:rgb(0,0,136)">get</span><span style=3D"color:rgb(102,1=
02,0)">();</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span s=
tyle=3D"color:rgb(136,0,0)">//Use `value`.</span><span style=3D"color:rgb(0=
,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span></div></code=
></div><br>I would like to see what you envision the `execution_context`-ba=
sed version of this code to look like. Feel free to invent whatever objects=
you would like to in order to make it work. I don't particularly need =
to see a full implementation of them, but a description of what those objec=
ts do would be nice. My main point is to see what day-to-day use of these m=
echanisms would look like.<br></div></blockquote></div></blockquote></span>=
</div></blockquote></div><br></div><div>I paste Evgeny's example from a=
wait_emu (<a href=3D"https://github.com/evgeny-panasyuk/await_emu" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fevgeny-panasyuk%2Fawait_emu\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG4PgUcyJJAaolrlvyjmrSv0IVa3g';ret=
urn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttp=
s%3A%2F%2Fgithub.com%2Fevgeny-panasyuk%2Fawait_emu\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNG4PgUcyJJAaolrlvyjmrSv0IVa3g';return true;">https://git=
hub.com/evgeny-<wbr>panasyuk/await_emu</a>):<br></div></div></blockquote><d=
iv><br>That's a nice library and interesting examples, but I'm afra=
id that it doesn't really address my point. I specifically called out t=
wo things I wanted such code to demonstrate: how to call such functions wit=
hout the suspension of those functions causing the caller to suspend too, a=
nd how it would avoid a context switch if the async process had already fin=
ished. The examples you've posted do not describe either.<br><br>For po=
int 1, the comment "await is not limited by "one level" as i=
n C#" seems to strongly suggest that suspending the function will not =
suspend <i>just</i> that function. It will suspend the entire call stack. S=
o, how do you call, for example `bar`, in a way that doesn't suspend yo=
urself if `bar` needs to suspend itself? I suspect it would look something =
like this:<br><br><div style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overfl=
ow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> task </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">packaged_task</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)>(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">bar</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>execution_context</span><span style=3D"color: #080;" class=3D"=
styled-by-prettify"><whatever></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> ec</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">task</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> ftr </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> task</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">get_future</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>ec</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">integer</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span></div></code></div><br>I'm sure you could wrap this in s=
ome kind of object. A `context_task<int(int)>`, which represents the =
ability to start and resume a function that returns a value via promise/fut=
ure, but that function gets executed in a context.<br><br>But `co_await` do=
esn't need to do that. It creates this machinery behind the scenes. And=
that's the whole point of `co_await`: you don't have to create the=
machinery yourself.<br><br>The caller of a function doesn't have to do=
something different to call a function that uses `co_await`. They call it,=
just like any other function. They interact with its return value as being=
exactly that function's return value (usually a future of some form). =
And if they want to `co_await` on that return value, to suspend themselves =
until it completes, they can do so. But they do not <i>have to</i>.<br><br>=
So I submit that this library, while clever, does not actually implement `c=
o_await`. It merely emulates syntax <i>similar</i> to `co_await`. But its b=
ehavior of this syntax is quite different, and fundamentally so.<br><br>I d=
o not intend for these questions to be an attack on `execution_context`. I =
have never doubted the inherent utility of `execution_context` as a general=
ized coroutine mechanism. I have never doubted its ability to be used as th=
e basis of incredibly useful and powerful higher level constructs. And I th=
ink it's almost criminal that it didn't make it into C++17.<br><br>=
However, after reading P0444, I have noticed a trend among the people who w=
ant an alternative to `co_await`. That trend being... they frequently misun=
derstand exactly what `co_await` is doing. They'll often describe it as=
"up-and-out" or "suspend-by-return" or some-such.<br><=
br>In particular, P0444 describes "suspend-by-return" with "=
In particular, when a function suspends, its caller must also suspend, and =
so must its caller=E2=80=99s caller, and so forth." That's not tru=
e at all. The caller only suspends if the caller <i>wants to</i> suspend. I=
t can choose instead to do something else if the value isn't ready. It =
can choose to store that future in an array of futures, that someone else w=
ill iterate over. And so forth. The important point being that the caller <=
i>gets to decide</i> if they want to take part in the continuation or go do=
something else.<br><br>What I doubt is that you can build an equivalent to=
`co_await` that can be as transparent as `co_await` ultimately is. Pretty =
much every example requires the caller to invoke such functions in a specia=
l way, based on whether or not it is a continuation function or not.<br></d=
iv></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fbb60521-431e-4f46-bdf7-64f0cd5f85c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fbb60521-431e-4f46-bdf7-64f0cd5f85c9=
%40isocpp.org</a>.<br />
------=_Part_1030_997199456.1480784963942--
------=_Part_1029_1160348016.1480784963941--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Sun, 4 Dec 2016 15:34:16 -0800 (PST)
Raw View
------=_Part_1172_2058623714.1480894456072
Content-Type: multipart/alternative;
boundary="----=_Part_1173_1174380977.1480894456073"
------=_Part_1173_1174380977.1480894456073
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, December 3, 2016 at 5:09:24 PM UTC, Nicol Bolas wrote:
>
> On Saturday, December 3, 2016 at 4:12:52 AM UTC-5, Oliver Kowalke wrote:
>>
>> 2016-12-03 7:01 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
>>
>>> With `co_await`, this code looks like this:
>>>>>
>>>>> std::future<Q> FunctionB()
>>>>> {
>>>>> co_return PlayWithT(co_await ProcessP());
>>>>> }
>>>>>
>>>>> void FunctionA()
>>>>> {
>>>>> auto ftr =3D FunctionB();
>>>>> while(ftr.wait_for(0) !=3D std::future_status::ready)
>>>>> //Do something else.
>>>>> auto value =3D ftr.get();
>>>>> //Use `value`.
>>>>> }
>>>>>
>>>>> I would like to see what you envision the `execution_context`-based=
=20
>>>>> version of this code to look like. Feel free to invent whatever objec=
ts you=20
>>>>> would like to in order to make it work. I don't particularly need to =
see a=20
>>>>> full implementation of them, but a description of what those objects =
do=20
>>>>> would be nice. My main point is to see what day-to-day use of these=
=20
>>>>> mechanisms would look like.
>>>>>
>>>>
>> I paste Evgeny's example from await_emu (
>> https://github.com/evgeny-panasyuk/await_emu):
>>
>
> That's a nice library and interesting examples, but I'm afraid that it=20
> doesn't really address my point. I specifically called out two things I=
=20
> wanted such code to demonstrate: how to call such functions without the=
=20
> suspension of those functions causing the caller to suspend too, and how =
it=20
> would avoid a context switch if the async process had already finished. T=
he=20
> examples you've posted do not describe either.
>
>
The number of logical context switches (i.e. continuation capture and=20
resumption) required for the context based code is exactly the same as for=
=20
the await code. The context model is a strict superset of the await model;=
=20
you only need to do a manual CPS conversion to demonstrate it . =20
Now, it is true that a library based context implementation might have a=20
slightly more expensive context switch cost than a compiler based=20
implementation, but that's immaterial.
=20
> For point 1, the comment "await is not limited by "one level" as in C#"=
=20
> seems to strongly suggest that suspending the function will not suspend=
=20
> *just* that function. It will suspend the entire call stack. So, how do=
=20
> you call, for example `bar`, in a way that doesn't suspend yourself if=20
> `bar` needs to suspend itself? I suspect it would look something like thi=
s:
>
>
context can capture the entire stack, but that's not the usual case. You=20
normally capture a suffix of the current call stack; from the last=20
resumption/context start to the next.
=20
> auto task =3D std::packaged_task<int(int)>(bar);
> execution_context<whatever> ec(task);
> auto ftr =3D task.get_future();
> ec(integer);
>
> I'm sure you could wrap this in some kind of object. A=20
> `context_task<int(int)>`, which represents the ability to start and resum=
e=20
> a function that returns a value via promise/future, but that function get=
s=20
> executed in a context.
>
> But `co_await` doesn't need to do that. It creates this machinery behind=
=20
> the scenes. And that's the whole point of `co_await`: you don't have to=
=20
> create the machinery yourself.
>
yes, you need to wrap bar in a new context; the only difference is that you=
=20
do it by wrapping it with some library function instead of hardcoding the=
=20
exact strategy using the keyword await. The final client of foo doesn't=20
need to know the details, they are simply invoking a future-returning=20
function; whether it is implemented via manual continuation chaining, await=
=20
magic or context is an implementation detail.
[...]
=20
>
> However, after reading P0444, I have noticed a trend among the people who=
=20
> want an alternative to `co_await`. That trend being... they frequently=20
> misunderstand exactly what `co_await` is doing. They'll often describe it=
=20
> as "up-and-out" or "suspend-by-return" or some-such.
>
>
I'm pretty sure they understand it.
=20
> In particular, P0444 describes "suspend-by-return" with "In particular,=
=20
> when a function suspends, its caller must also suspend, and so must its=
=20
> caller=E2=80=99s caller, and so forth." That's not true at all. The calle=
r only=20
> suspends if the caller *wants to* suspend. It can choose instead to do=20
> something else if the value isn't ready. It can choose to store that futu=
re=20
> in an array of futures, that someone else will iterate over. And so forth=
..=20
> The important point being that the caller *gets to decide* if they want=
=20
> to take part in the continuation or go do something else.
>
Of course they don't have to, that's has never been the issue. The problem=
=20
is that when they really need to [1], every function in the call stack has =
=20
to cooperate to do that, which breaks genericity (and, without specific=20
optimizations it reduces to heap allocating each frame).
-- gpd
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0ed595e7-6032-4608-99d0-ee04f483f4a3%40isocpp.or=
g.
------=_Part_1173_1174380977.1480894456073
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, December 3, 2016 at 5:09:24 PM UTC, Nicol Bol=
as 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">On S=
aturday, December 3, 2016 at 4:12:52 AM UTC-5, Oliver Kowalke wrote:<blockq=
uote 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">2016-12-03 7:01 GMT+01:00 Nicol Bolas <span dir=3D"ltr"><<a rel=
=3D"nofollow">jmck...@gmail.com</a>></span>:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div dir=3D"ltr"><span></span><span><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"><div>With `co_await`, this code looks like thi=
s:<br><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px"><code><div><span style=3D=
"color:rgb(0,0,0)">std</span><span style=3D"color:rgb(102,102,0)">::</span>=
<span style=3D"color:rgb(0,0,0)">future</span><span style=3D"color:rgb(102,=
102,0)"><</span><span style=3D"color:rgb(0,0,0)">Q</span><span style=3D"=
color:rgb(102,102,0)">></span><span style=3D"color:rgb(0,0,0)"> </span><=
span style=3D"color:rgb(102,0,102)">FunctionB</span><span style=3D"color:rg=
b(102,102,0)">()</span><span style=3D"color:rgb(0,0,0)"><br></span><span st=
yle=3D"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br><=
/span><span style=3D"color:rgb(0,0,0)">=C2=A0 co_return </span><code><span =
style=3D"color:rgb(0,0,0)"></span><span style=3D"color:rgb(102,0,102)">Play=
WithT</span><span style=3D"color:rgb(102,102,0)">(</span><code><span style=
=3D"color:rgb(0,0,0)">co_await </span><span style=3D"color:rgb(102,0,102)">=
ProcessP</span><span style=3D"color:rgb(102,102,0)">()</span><span style=3D=
"color:rgb(102,102,0)"></span></code><span style=3D"color:rgb(102,102,0)">)=
;</span><span style=3D"color:rgb(0,0,0)"><br></span></code><span style=3D"c=
olor:rgb(102,102,0)"></span><span style=3D"color:rgb(0,0,0)"></span><span s=
tyle=3D"color:rgb(102,102,0)">}</span><span style=3D"color:rgb(0,0,0)"><br>=
<br></span><span style=3D"color:rgb(0,0,136)">void</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,0,102)">FunctionA</span=
><span style=3D"color:rgb(102,102,0)">()</span><span style=3D"color:rgb(0,0=
,0)"><br></span><span style=3D"color:rgb(102,102,0)">{</span><span style=3D=
"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rgb(0,0,136)">aut=
o</span><span style=3D"color:rgb(0,0,0)"> ftr </span><span style=3D"color:r=
gb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span sty=
le=3D"color:rgb(102,0,102)">FunctionB</span><span style=3D"color:rgb(102,10=
2,0)">();</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span st=
yle=3D"color:rgb(0,0,136)">while</span><span style=3D"color:rgb(102,102,0)"=
>(</span><span style=3D"color:rgb(0,0,0)">ftr</span><span style=3D"color:rg=
b(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">wait_for</span><span=
style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,102,102)=
">0</span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color=
:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">!=3D</span><span =
style=3D"color:rgb(0,0,0)"> std</span><span style=3D"color:rgb(102,102,0)">=
::</span><span style=3D"color:rgb(0,0,0)">future_status</span><span style=
=3D"color:rgb(102,102,0)">::</span><span style=3D"color:rgb(0,0,0)">ready</=
span><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(=
0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(136,0,0)">//Do so=
mething else.</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><spa=
n style=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(0,0,0)">=
value </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=3D=
"color:rgb(0,0,0)"> ftr</span><span style=3D"color:rgb(102,102,0)">.</span>=
<span style=3D"color:rgb(0,0,136)">get</span><span style=3D"color:rgb(102,1=
02,0)">();</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span s=
tyle=3D"color:rgb(136,0,0)">//Use `value`.</span><span style=3D"color:rgb(0=
,0,0)"><br></span><span style=3D"color:rgb(102,102,0)">}</span></div></code=
></div><br>I would like to see what you envision the `execution_context`-ba=
sed version of this code to look like. Feel free to invent whatever objects=
you would like to in order to make it work. I don't particularly need =
to see a full implementation of them, but a description of what those objec=
ts do would be nice. My main point is to see what day-to-day use of these m=
echanisms would look like.<br></div></blockquote></div></blockquote></span>=
</div></blockquote></div><br></div><div>I paste Evgeny's example from a=
wait_emu (<a href=3D"https://github.com/evgeny-panasyuk/await_emu" rel=3D"n=
ofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://www.goog=
le.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fevgeny-panasyuk%2Fawait_emu\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG4PgUcyJJAaolrlvyjmrSv0IVa3g';retur=
n true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%=
3A%2F%2Fgithub.com%2Fevgeny-panasyuk%2Fawait_emu\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNG4PgUcyJJAaolrlvyjmrSv0IVa3g';return true;">https://githu=
b.com/evgeny-<wbr>panasyuk/await_emu</a>):<br></div></div></blockquote><div=
><br>That's a nice library and interesting examples, but I'm afraid=
that it doesn't really address my point. I specifically called out two=
things I wanted such code to demonstrate: how to call such functions witho=
ut the suspension of those functions causing the caller to suspend too, and=
how it would avoid a context switch if the async process had already finis=
hed. The examples you've posted do not describe either.<br><br></div></=
div></blockquote><div><br>The number of logical context switches (i.e. cont=
inuation capture and resumption) required for the context based code is exa=
ctly the same as for the await code. The context model is a strict superset=
of the await model; you only need to do a manual CPS conversion to demonst=
rate it .=C2=A0 <br><br>Now, it is true that a library based context implem=
entation might have a slightly more expensive context switch cost than a co=
mpiler based implementation, but that's immaterial.<br><br>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>For poin=
t 1, the comment "await is not limited by "one level" as in =
C#" seems to strongly suggest that suspending the function will not su=
spend <i>just</i> that function. It will suspend the entire call stack. So,=
how do you call, for example `bar`, in a way that doesn't suspend your=
self if `bar` needs to suspend itself? I suspect it would look something li=
ke this:<br><br></div></div></blockquote><div><br>context can capture the e=
ntire stack, but that's not the usual case. You normally capture a suff=
ix of the current call stack; from the last resumption/context start to the=
next.<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><div style=3D"background-color:rgb(250,250,250);border-color:=
rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span styl=
e=3D"color:#008">auto</span><span style=3D"color:#000"> task </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> std</span><span s=
tyle=3D"color:#660">::</span><span style=3D"color:#000">packaged_task</span=
><span style=3D"color:#660"><</span><span style=3D"color:#008">int</span=
><span style=3D"color:#660">(</span><span style=3D"color:#008">int</span><s=
pan style=3D"color:#660">)>(</span><span style=3D"color:#000">b<wbr>ar</=
span><span style=3D"color:#660">);</span><span style=3D"color:#000"><br>exe=
cution_context</span><span style=3D"color:#080"><whatever></span><spa=
n style=3D"color:#000"> ec</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#000">task</span><span style=3D"color:#660">);</span><span st=
yle=3D"color:#000"><br></span><span style=3D"color:#008">auto</span><span s=
tyle=3D"color:#000"> ftr </span><span style=3D"color:#660">=3D</span><span =
style=3D"color:#000"> task</span><span style=3D"color:#660">.</span><span s=
tyle=3D"color:#000">get_future</span><span style=3D"color:#660">();</span><=
span style=3D"color:#000"><br>ec</span><span style=3D"color:#660">(</span><=
span style=3D"color:#000">integer</span><span style=3D"color:#660">);</span=
><span style=3D"color:#000"><br></span></div></code></div><br>I'm sure =
you could wrap this in some kind of object. A `context_task<int(int)>=
`, which represents the ability to start and resume a function that returns=
a value via promise/future, but that function gets executed in a context.<=
br><br>But `co_await` doesn't need to do that. It creates this machiner=
y behind the scenes. And that's the whole point of `co_await`: you don&=
#39;t have to create the machinery yourself.<br></div></div></blockquote><d=
iv><br>yes, you need to wrap bar in a new context; the only difference is t=
hat you do it by wrapping it with some library function instead of hardcodi=
ng the exact strategy using the keyword await. The final client of foo does=
n't need to know the details, they are simply invoking a future-returni=
ng function; whether it is implemented via manual continuation chaining, aw=
ait magic or context is an implementation detail.<br><br>=C2=A0[...]<br></d=
iv>=C2=A0<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=
>However, after reading P0444, I have noticed a trend among the people who =
want an alternative to `co_await`. That trend being... they frequently misu=
nderstand exactly what `co_await` is doing. They'll often describe it a=
s "up-and-out" or "suspend-by-return" or some-such.<br>=
<br></div></div></blockquote><div><br>I'm pretty sure they understand i=
t.<br>=C2=A0<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>In particular, P0444 describes "suspend-by-return" =
with "In particular, when a function suspends, its caller must also su=
spend, and so must its caller=E2=80=99s caller, and so forth." That=
9;s not true at all. The caller only suspends if the caller <i>wants to</i>=
suspend. It can choose instead to do something else if the value isn't=
ready. It can choose to store that future in an array of futures, that som=
eone else will iterate over. And so forth. The important point being that t=
he caller <i>gets to decide</i> if they want to take part in the continuati=
on or go do something else.<br></div></div></blockquote><div><br>Of course =
they don't have to, that's has never been the issue. The problem is=
that when they really need to [1], every function in the call stack has=C2=
=A0 to cooperate to do that, which breaks genericity (and, without specific=
optimizations it reduces=C2=A0 to heap allocating each frame).<br><br>-- g=
pd<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0ed595e7-6032-4608-99d0-ee04f483f4a3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0ed595e7-6032-4608-99d0-ee04f483f4a3=
%40isocpp.org</a>.<br />
------=_Part_1173_1174380977.1480894456073--
------=_Part_1172_2058623714.1480894456072--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 4 Dec 2016 19:38:27 -0800 (PST)
Raw View
------=_Part_1851_501140363.1480909107457
Content-Type: multipart/alternative;
boundary="----=_Part_1852_1940736956.1480909107458"
------=_Part_1852_1940736956.1480909107458
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sunday, December 4, 2016 at 6:34:16 PM UTC-5, Giovanni Piero Deretta=20
wrote:
>
> On Saturday, December 3, 2016 at 5:09:24 PM UTC, Nicol Bolas wrote:
>>
>> On Saturday, December 3, 2016 at 4:12:52 AM UTC-5, Oliver Kowalke wrote:
>>>
>>> 2016-12-03 7:01 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
>>>
>>>> For point 1, the comment "await is not limited by "one level" as in C#=
"=20
>> seems to strongly suggest that suspending the function will not suspend=
=20
>> *just* that function. It will suspend the entire call stack. So, how do=
=20
>> you call, for example `bar`, in a way that doesn't suspend yourself if=
=20
>> `bar` needs to suspend itself? I suspect it would look something like th=
is:
>>
>
> context can capture the entire stack, but that's not the usual case. You=
=20
> normally capture a suffix of the current call stack; from the last=20
> resumption/context start to the next.
>
I'm aware of that. My point was that you didn't show what that looked like.=
=20
What code do I have to write to do that, to specify where that "suffix of=
=20
the current call stack" is?
auto task =3D std::packaged_task<int(int)>(bar);
>> execution_context<whatever> ec(task);
>> auto ftr =3D task.get_future();
>> ec(integer);
>>
>> I'm sure you could wrap this in some kind of object. A=20
>> `context_task<int(int)>`, which represents the ability to start and resu=
me=20
>> a function that returns a value via promise/future, but that function ge=
ts=20
>> executed in a context.
>>
>> But `co_await` doesn't need to do that. It creates this machinery behind=
=20
>> the scenes. And that's the whole point of `co_await`: you don't have to=
=20
>> create the machinery yourself.
>>
>
> yes, you need to wrap bar in a new context; the only difference is that=
=20
> you do it by wrapping it with some library function instead of hardcoding=
=20
> the exact strategy using the keyword await. The final client of foo doesn=
't=20
> need to know the details, they are simply invoking a future-returning=20
> function; whether it is implemented via manual continuation chaining, awa=
it=20
> magic or context is an implementation detail.
>
My point is that, with `execution_context`, there must be some form of code=
=20
between the code receiving the future-like thing and the `bar` function=20
which actually "awaits", something else has to live. With `co_await`, no=20
such code is *visible* to the user. The fact that this code is hidden is=20
the primary advantage of `co_await`, one which `execution_context` as a=20
pure library feature cannot match.
Again, that's no slight against `execution_context`. But `co_await` is a=20
focused tool for a specific job.
[...]
> =20
>>
>> However, after reading P0444, I have noticed a trend among the people wh=
o=20
>> want an alternative to `co_await`. That trend being... they frequently=
=20
>> misunderstand exactly what `co_await` is doing. They'll often describe i=
t=20
>> as "up-and-out" or "suspend-by-return" or some-such.
>>
>
> I'm pretty sure they understand it.
>
And yet, they keep describing it as if every level of code is expected to=
=20
have a `co_await` in it.
Now yes, `co_await` most certainly can *lead* to such code. But that use=20
case is not what the feature is for. Personally, I think if=20
`execution_context` is available alongside `co_await`, you'll find people=
=20
will be much less likely to use `co_await` improperly.
In particular, P0444 describes "suspend-by-return" with "In particular,=20
>> when a function suspends, its caller must also suspend, and so must its=
=20
>> caller=E2=80=99s caller, and so forth." That's not true at all. The call=
er only=20
>> suspends if the caller *wants to* suspend. It can choose instead to do=
=20
>> something else if the value isn't ready. It can choose to store that fut=
ure=20
>> in an array of futures, that someone else will iterate over. And so fort=
h.=20
>> The important point being that the caller *gets to decide* if they want=
=20
>> to take part in the continuation or go do something else.
>>
>
> Of course they don't have to, that's has never been the issue. The proble=
m=20
> is that when they really need to [1], every function in the call stack ha=
s =20
> to cooperate to do that, which breaks genericity (and, without specific=
=20
> optimizations it reduces to heap allocating each frame).
>
I recognize that. But that is precisely why saying that `execution_context`=
=20
can match `co_await` is wrong.
`execution_context` is like a utility knife. You can do a lot of things=20
with it. You can cut lots of things with it. It's very handy to have one=20
when in the wilderness.
`co_await` is like a scalpel. It's only good for one thing. But it is *very=
=20
good* at that one thing. In surgery, the utility knife is large and=20
unwieldy, where the scalpel is sleek and precise.
`co_await` is primary a mechanism for continuing a function. That's its=20
job, and that's the situation where it is second-to-none in terms of code=
=20
clarity and utility. If you just need to write some code that halts,=20
scheduling its resumption with some other object that represents the value=
=20
being halted on, it is without peer. It requires minimal code writing on=20
the user's part. It requires nothing at all from the *direct* caller,=20
outside of what is apparent. It requires no evident middleware layer=20
between the caller and the suspending function itself.
`execution_context` could do the same job, but it would be large and=20
unwieldy, like the utility knife.
`co_await` breaks down the *moment* you stray from that particular use=20
case. It is *especially* bad at generators; despite the added machinery to=
=20
support them, the fact that you can't yield across functions makes it very=
=20
difficult to work with them.
`co_await` is most certainly not a generic solution to the "coroutine"=20
problem. But in its primary domain, as a solution for basic function=20
continuations, it's *really* hard to beat in terms of overall code clarity.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/852a26d0-eb38-445c-9c89-76ebe2dcaa6c%40isocpp.or=
g.
------=_Part_1852_1940736956.1480909107458
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, December 4, 2016 at 6:34:16 PM UTC-5, Giovanni =
Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Saturday, December 3, 2016 at 5:09:24 PM UTC, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, Dece=
mber 3, 2016 at 4:12:52 AM UTC-5, Oliver Kowalke wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">2016-1=
2-03 7:01 GMT+01:00 Nicol Bolas <span dir=3D"ltr"><<a rel=3D"nofollow">j=
mck...@gmail.com</a>></span>:<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></div><div dir=3D"ltr"><span></span><span></span></div></bl=
ockquote></div></div></div></blockquote></div></blockquote></div></blockquo=
te><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=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>For point 1,=
the comment "await is not limited by "one level" as in C#&q=
uot; seems to strongly suggest that suspending the function will not suspen=
d <i>just</i> that function. It will suspend the entire call stack. So, how=
do you call, for example `bar`, in a way that doesn't suspend yourself=
if `bar` needs to suspend itself? I suspect it would look something like t=
his:<br></div></div></blockquote><div><br>context can capture the entire st=
ack, but that's not the usual case. You normally capture a suffix of th=
e current call stack; from the last resumption/context start to the next.<b=
r></div></div></blockquote><div><br>I'm aware of that. My point was tha=
t you didn't show what that looked like. What code do I have to write t=
o do that, to specify where that "suffix of the current call stack&quo=
t; is?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187=
,187,187);border-style:solid;border-width:1px"><code><div><span style=3D"co=
lor:#008">auto</span><span style=3D"color:#000"> task </span><span style=3D=
"color:#660">=3D</span><span style=3D"color:#000"> std</span><span style=3D=
"color:#660">::</span><span style=3D"color:#000">packaged_task</span><span =
style=3D"color:#660"><</span><span style=3D"color:#008">int</span><span =
style=3D"color:#660">(</span><span style=3D"color:#008">int</span><span sty=
le=3D"color:#660">)>(</span><span style=3D"color:#000">b<wbr>ar</span><s=
pan style=3D"color:#660">);</span><span style=3D"color:#000"><br>execution_=
context</span><span style=3D"color:#080"><whatever></span><span style=
=3D"color:#000"> ec</span><span style=3D"color:#660">(</span><span style=3D=
"color:#000">task</span><span style=3D"color:#660">);</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#008">auto</span><span style=3D=
"color:#000"> ftr </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> task</span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">get_future</span><span style=3D"color:#660">();</span><span=
style=3D"color:#000"><br>ec</span><span style=3D"color:#660">(</span><span=
style=3D"color:#000">integer</span><span style=3D"color:#660">);</span><sp=
an style=3D"color:#000"><br></span></div></code></div><br>I'm sure you =
could wrap this in some kind of object. A `context_task<int(int)>`, w=
hich represents the ability to start and resume a function that returns a v=
alue via promise/future, but that function gets executed in a context.<br><=
br>But `co_await` doesn't need to do that. It creates this machinery be=
hind the scenes. And that's the whole point of `co_await`: you don'=
t have to create the machinery yourself.<br></div></div></blockquote><div><=
br>yes, you need to wrap bar in a new context; the only difference is that =
you do it by wrapping it with some library function instead of hardcoding t=
he exact strategy using the keyword await. The final client of foo doesn=
9;t need to know the details, they are simply invoking a future-returning f=
unction; whether it is implemented via manual continuation chaining, await =
magic or context is an implementation detail.<br></div></div></blockquote><=
div><br>My point is that, with `execution_context`, there must be some form=
of code between the code receiving the future-like thing and the `bar` fun=
ction which actually "awaits", something else has to live. With `=
co_await`, no such code is <i>visible</i> to the user. The fact that this c=
ode is hidden is the primary advantage of `co_await`, one which `execution_=
context` as a pure library feature cannot match.<br><br>Again, that's n=
o slight against `execution_context`. But `co_await` is a focused tool for =
a specific job.<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div>=C2=A0[...]<br></div>=C2=A0<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>However, after reading P0444, I have not=
iced a trend among the people who want an alternative to `co_await`. That t=
rend being... they frequently misunderstand exactly what `co_await` is doin=
g. They'll often describe it as "up-and-out" or "suspend=
-by-return" or some-such.<br></div></div></blockquote><div><br>I'm=
pretty sure they understand it.<br></div></div></blockquote><div><br>And y=
et, they keep describing it as if every level of code is expected to have a=
`co_await` in it.<br><br>Now yes, `co_await` most certainly can <i>lead</i=
> to such code. But that use case is not what the feature is for. Personall=
y, I think if `execution_context` is available alongside `co_await`, you=
9;ll find people will be much less likely to use `co_await` improperly.<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"><di=
v></div><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>In pa=
rticular, P0444 describes "suspend-by-return" with "In parti=
cular, when a function suspends, its caller must also suspend, and so must =
its caller=E2=80=99s caller, and so forth." That's not true at all=
.. The caller only suspends if the caller <i>wants to</i> suspend. It can ch=
oose instead to do something else if the value isn't ready. It can choo=
se to store that future in an array of futures, that someone else will iter=
ate over. And so forth. The important point being that the caller <i>gets t=
o decide</i> if they want to take part in the continuation or go do somethi=
ng else.<br></div></div></blockquote><div><br>Of course they don't have=
to, that's has never been the issue. The problem is that when they rea=
lly need to [1], every function in the call stack has=C2=A0 to cooperate to=
do that, which breaks genericity (and, without specific optimizations it r=
educes=C2=A0 to heap allocating each frame).<br></div></div></blockquote><d=
iv><br>I recognize that. But that is precisely why saying that `execution_c=
ontext` can match `co_await` is wrong.<br><br>`execution_context` is like a=
utility knife. You can do a lot of things with it. You can cut lots of thi=
ngs with it. It's very handy to have one when in the wilderness.<br><br=
>`co_await` is like a scalpel. It's only good for one thing. But it is =
<i>very good</i> at that one thing. In surgery, the utility knife is large =
and unwieldy, where the scalpel is sleek and precise.<br><br>`co_await` is =
primary a mechanism for continuing a function. That's its job, and that=
's the situation where it is second-to-none in terms of code clarity an=
d utility. If you just need to write some code that halts, scheduling its r=
esumption with some other object that represents the value being halted on,=
it is without peer. It requires minimal code writing on the user's par=
t. It requires nothing at all from the <i>direct</i> caller, outside of wha=
t is apparent. It requires no evident middleware layer between the caller a=
nd the suspending function itself.<br><br>`execution_context` could do the =
same job, but it would be large and unwieldy, like the utility knife.<br><b=
r>`co_await` breaks down the <i>moment</i> you stray from that particular u=
se case. It is <i>especially</i> bad at generators; despite the added machi=
nery to support them, the fact that you can't yield across functions ma=
kes it very difficult to work with them.<br><br>`co_await` is most certainl=
y not a generic solution to the "coroutine" problem. But in its p=
rimary domain, as a solution for basic function continuations, it's <i>=
really</i> hard to beat in terms of overall code clarity.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/852a26d0-eb38-445c-9c89-76ebe2dcaa6c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/852a26d0-eb38-445c-9c89-76ebe2dcaa6c=
%40isocpp.org</a>.<br />
------=_Part_1852_1940736956.1480909107458--
------=_Part_1851_501140363.1480909107457--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Mon, 5 Dec 2016 03:07:59 -0800 (PST)
Raw View
------=_Part_1387_1151703476.1480936079294
Content-Type: multipart/alternative;
boundary="----=_Part_1388_1529013103.1480936079295"
------=_Part_1388_1529013103.1480936079295
Content-Type: text/plain; charset=UTF-8
On Monday, December 5, 2016 at 3:38:27 AM UTC, Nicol Bolas wrote:
>
> On Sunday, December 4, 2016 at 6:34:16 PM UTC-5, Giovanni Piero Deretta
> wrote:
>>
>> On Saturday, December 3, 2016 at 5:09:24 PM UTC, Nicol Bolas wrote:
>>>
>>> On Saturday, December 3, 2016 at 4:12:52 AM UTC-5, Oliver Kowalke wrote:
>>>>
>>>> 2016-12-03 7:01 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
>>>>
>>>>> For point 1, the comment "await is not limited by "one level" as in
>>> C#" seems to strongly suggest that suspending the function will not suspend
>>> *just* that function. It will suspend the entire call stack. So, how do
>>> you call, for example `bar`, in a way that doesn't suspend yourself if
>>> `bar` needs to suspend itself? I suspect it would look something like this:
>>>
>>
>> context can capture the entire stack, but that's not the usual case. You
>> normally capture a suffix of the current call stack; from the last
>> resumption/context start to the next.
>>
>
> I'm aware of that. My point was that you didn't show what that looked
> like. What code do I have to write to do that, to specify where that
> "suffix of the current call stack" is?
>
context foo_ctx(context caller, args){
// async function implementation here
}
future<T> foo(args...)
{
return async(foo_ctx);
}
as an end user of an async function you do not necessarily need to know.
The function itself may setup the capture and restoring, although, for
composition it is useful to both expose an opaque future returning function
(foo) and an explicit context passing one for composition (foo_ctx). The
former is implemented in therm of the latter with a library combinator (I'm
calling it async here as it conceptually the same as async for threads).
>
> I'm sure you could wrap this in some kind of object. A
>>> `context_task<int(int)>`, which represents the ability to start and resume
>>> a function that returns a value via promise/future, but that function gets
>>> executed in a context.
>>>
>>> But `co_await` doesn't need to do that. It creates this machinery behind
>>> the scenes. And that's the whole point of `co_await`: you don't have to
>>> create the machinery yourself.
>>>
>>
>> yes, you need to wrap bar in a new context; the only difference is that
>> you do it by wrapping it with some library function instead of hardcoding
>> the exact strategy using the keyword await. The final client of foo doesn't
>> need to know the details, they are simply invoking a future-returning
>> function; whether it is implemented via manual continuation chaining, await
>> magic or context is an implementation detail.
>>
>
> My point is that, with `execution_context`, there must be some form of
> code between the code receiving the future-like thing and the `bar`
> function which actually "awaits", something else has to live. With
> `co_await`, no such code is *visible* to the user. The fact that this
> code is hidden is the primary advantage of `co_await`, one which
> `execution_context` as a pure library feature cannot match.
>
The code can be hidden inside bar itself (by either splitting it in a bar +
bar_ctx or with an embedded lambda.
[...]
> `co_await` is most certainly not a generic solution to the "coroutine"
> problem. But in its primary domain, as a solution for basic function
> continuations, it's *really* hard to beat in terms of overall code
> clarity.
>
I do not necessarily disagree (except that noticing that co_await is
anything but simple to understand and, worst, most of the moving parts are
hidden under compiler magic). Similarly to OpenMP parallel compiler
annotations to handle some specific threading cases, co_await is a compiler
annotation to handle some specific continuation passing cases. Both have
their use cases.
But I would also add that, if the Parallelism TR is the way forward,
open-mp style parallelism are be unlikely to make it to standard C++ in the
form of compiler annotations and is most likely going to be hidden under a
library layer as it seems that that's the preferred way forward.
-- 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f937e21-8d7a-43db-856e-70d4ae3a450f%40isocpp.org.
------=_Part_1388_1529013103.1480936079295
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, December 5, 2016 at 3:38:27 AM UTC, Nicol Bolas=
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">On Sun=
day, December 4, 2016 at 6:34:16 PM UTC-5, Giovanni Piero Deretta wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, December=
3, 2016 at 5:09:24 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">On Saturday, December 3, 2016 at 4:12:52 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"><div><div class=3D"gmail_quote">2016-12-03 7:01 GMT+01:00 Nicol Bo=
las <span dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></sp=
an>:<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></div><div d=
ir=3D"ltr"><span></span><span></span></div></blockquote></div></div></div><=
/blockquote></div></blockquote></div></blockquote><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>For point 1, the comment "await is not l=
imited by "one level" as in C#" seems to strongly suggest th=
at suspending the function will not suspend <i>just</i> that function. It w=
ill suspend the entire call stack. So, how do you call, for example `bar`, =
in a way that doesn't suspend yourself if `bar` needs to suspend itself=
? I suspect it would look something like this:<br></div></div></blockquote>=
<div><br>context can capture the entire stack, but that's not the usual=
case. You normally capture a suffix of the current call stack; from the la=
st resumption/context start to the next.<br></div></div></blockquote><div><=
br>I'm aware of that. My point was that you didn't show what that l=
ooked like. What code do I have to write to do that, to specify where that =
"suffix of the current call stack" is?<br></div></div></blockquot=
e><div><br>context foo_ctx(context caller, args){<br>// async function impl=
ementation here<br>}<br><br>future<T> foo(args...)<br>{<br>=C2=A0=C2=
=A0=C2=A0=C2=A0 return async(foo_ctx);<br>}<br>=C2=A0</div><div>as an end u=
ser of an async function you do not necessarily need to know. The function =
itself may setup the capture and restoring, although, for composition it is=
useful to both expose an opaque future returning function (foo) and an exp=
licit context passing one for composition (foo_ctx). The former is implemen=
ted in therm of the latter with a library combinator (I'm calling it as=
ync here as it conceptually the same as async for threads).<br>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div>I'm sure you could wrap this in some=
kind of object. A `context_task<int(int)>`, which represents the abi=
lity to start and resume a function that returns a value via promise/future=
, but that function gets executed in a context.<br><br>But `co_await` doesn=
't need to do that. It creates this machinery behind the scenes. And th=
at's the whole point of `co_await`: you don't have to create the ma=
chinery yourself.<br></div></div></blockquote><div><br>yes, you need to wra=
p bar in a new context; the only difference is that you do it by wrapping i=
t with some library function instead of hardcoding the exact strategy using=
the keyword await. The final client of foo doesn't need to know the de=
tails, they are simply invoking a future-returning function; whether it is =
implemented via manual continuation chaining, await magic or context is an =
implementation detail.<br></div></div></blockquote><div><br>My point is tha=
t, with `execution_context`, there must be some form of code between the co=
de receiving the future-like thing and the `bar` function which actually &q=
uot;awaits", something else has to live. With `co_await`, no such code=
is <i>visible</i> to the user. The fact that this code is hidden is the pr=
imary advantage of `co_await`, one which `execution_context` as a pure libr=
ary feature cannot match.<br></div></div></blockquote><div><br>The code can=
be hidden inside bar itself (by either splitting it in a bar + bar_ctx or =
with an embedded lambda.<br><br>[...] <br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div>`co_await` is most certainly not a =
generic solution to the "coroutine" problem. But in its primary d=
omain, as a solution for basic function continuations, it's <i>really</=
i> hard to beat in terms of overall code clarity.<br></div></div></blockquo=
te><div><br>I do not necessarily disagree (except that noticing that co_awa=
it is anything but simple to understand and, worst, most of the moving part=
s are hidden under compiler magic).=C2=A0 Similarly to OpenMP parallel comp=
iler annotations to handle some specific threading cases, co_await is a com=
piler annotation to handle some specific continuation passing cases. Both h=
ave their use cases.<br><br>But I would also add that, if the Parallelism T=
R is the way forward, open-mp style parallelism are be unlikely to make it =
to standard C++ in the form of compiler annotations and is most likely goin=
g to be hidden under a library layer as it seems that that's the prefer=
red way forward.<br><br>-- gpd<br><br><br>=C2=A0</div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1f937e21-8d7a-43db-856e-70d4ae3a450f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1f937e21-8d7a-43db-856e-70d4ae3a450f=
%40isocpp.org</a>.<br />
------=_Part_1388_1529013103.1480936079295--
------=_Part_1387_1151703476.1480936079294--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 6 Dec 2016 13:43:14 -0800 (PST)
Raw View
------=_Part_2669_1589685125.1481060594638
Content-Type: multipart/alternative;
boundary="----=_Part_2670_564983418.1481060594638"
------=_Part_2670_564983418.1481060594638
Content-Type: text/plain; charset=UTF-8
On Monday, December 5, 2016 at 6:07:59 AM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Monday, December 5, 2016 at 3:38:27 AM UTC, Nicol Bolas wrote:
>>
>> On Sunday, December 4, 2016 at 6:34:16 PM UTC-5, Giovanni Piero Deretta
>> wrote:
>>>
>>> On Saturday, December 3, 2016 at 5:09:24 PM UTC, Nicol Bolas wrote:
>>>>
>>>> On Saturday, December 3, 2016 at 4:12:52 AM UTC-5, Oliver Kowalke wrote:
>>>>>
>>>>> 2016-12-03 7:01 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
>>>>>
>>>>>> For point 1, the comment "await is not limited by "one level" as in
>>>> C#" seems to strongly suggest that suspending the function will not suspend
>>>> *just* that function. It will suspend the entire call stack. So, how
>>>> do you call, for example `bar`, in a way that doesn't suspend yourself if
>>>> `bar` needs to suspend itself? I suspect it would look something like this:
>>>>
>>>
>>> context can capture the entire stack, but that's not the usual case. You
>>> normally capture a suffix of the current call stack; from the last
>>> resumption/context start to the next.
>>>
>>
>> I'm aware of that. My point was that you didn't show what that looked
>> like. What code do I have to write to do that, to specify where that
>> "suffix of the current call stack" is?
>>
>
> context foo_ctx(context caller, args){
> // async function implementation here
> }
>
> future<T> foo(args...)
> {
> return async(foo_ctx);
> }
>
> as an end user of an async function you do not necessarily need to know.
> The function itself may setup the capture and restoring, although, for
> composition it is useful to both expose an opaque future returning function
> (foo) and an explicit context passing one for composition (foo_ctx). The
> former is implemented in therm of the latter with a library combinator (I'm
> calling it async here as it conceptually the same as async for threads).
>
>
>>
>> I'm sure you could wrap this in some kind of object. A
>>>> `context_task<int(int)>`, which represents the ability to start and resume
>>>> a function that returns a value via promise/future, but that function gets
>>>> executed in a context.
>>>>
>>>> But `co_await` doesn't need to do that. It creates this machinery
>>>> behind the scenes. And that's the whole point of `co_await`: you don't have
>>>> to create the machinery yourself.
>>>>
>>>
>>> yes, you need to wrap bar in a new context; the only difference is that
>>> you do it by wrapping it with some library function instead of hardcoding
>>> the exact strategy using the keyword await. The final client of foo doesn't
>>> need to know the details, they are simply invoking a future-returning
>>> function; whether it is implemented via manual continuation chaining, await
>>> magic or context is an implementation detail.
>>>
>>
>> My point is that, with `execution_context`, there must be some form of
>> code between the code receiving the future-like thing and the `bar`
>> function which actually "awaits", something else has to live. With
>> `co_await`, no such code is *visible* to the user. The fact that this
>> code is hidden is the primary advantage of `co_await`, one which
>> `execution_context` as a pure library feature cannot match.
>>
>
> The code can be hidden inside bar itself (by either splitting it in a bar
> + bar_ctx or with an embedded lambda.
>
Regardless of which side it is on, there has to be a layer between the
caller who gets a future and the actual resumable function providing that
value.
>
> [...]
>
>> `co_await` is most certainly not a generic solution to the "coroutine"
>> problem. But in its primary domain, as a solution for basic function
>> continuations, it's *really* hard to beat in terms of overall code
>> clarity.
>>
>
> I do not necessarily disagree (except that noticing that co_await is
> anything but simple to understand and, worst, most of the moving parts are
> hidden under compiler magic).
>
It's really simple to understand... so long as you never, *ever* have to
write an await-able type, a future type, or anything remotely related to
them. As a client of some existing machinery, it's great.
The guts however are the stuff of nightmares. I really think there's a
simpler language feature trying desperately to get out from under
`co_await`'s vast machinery. And I think the over-complicated nature of it
comes from trying to handle things it really has no business trying to
handle (like generators with `co_yield` and so forth).
Speaking of generators, does the more modern `execution_context` system
have some way of handling generators in a way that permits guaranteed
elision? If not, that sounds like a great place for some kind of language
feature, even if it gets tied into a library to do the actual
suspension/resumption.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8ce1d3db-7fd0-4bb2-9871-e0f7e83a0010%40isocpp.org.
------=_Part_2670_564983418.1481060594638
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, December 5, 2016 at 6:07:59 AM UTC-5, G=
iovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">On Monday, December 5, 2016 at 3:38:27 AM UTC, Nicol Bolas w=
rote:<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">On Sunday, De=
cember 4, 2016 at 6:34:16 PM UTC-5, Giovanni Piero Deretta wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div dir=3D"ltr">On Saturday, December 3, 201=
6 at 5:09:24 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr">On Saturday, December 3, 2016 at 4:12:52 AM UTC-5, Oli=
ver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">2016-12-03 7:01 GMT+01:00 Nicol Bolas <span=
dir=3D"ltr"><<a rel=3D"nofollow">jmck...@gmail.com</a>></span>:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div></div><div dir=3D"ltr=
"><span></span><span></span></div></blockquote></div></div></div></blockquo=
te></div></blockquote></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><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>For point 1, the comment "await is not limited =
by "one level" as in C#" seems to strongly suggest that susp=
ending the function will not suspend <i>just</i> that function. It will sus=
pend the entire call stack. So, how do you call, for example `bar`, in a wa=
y that doesn't suspend yourself if `bar` needs to suspend itself? I sus=
pect it would look something like this:<br></div></div></blockquote><div><b=
r>context can capture the entire stack, but that's not the usual case. =
You normally capture a suffix of the current call stack; from the last resu=
mption/context start to the next.<br></div></div></blockquote><div><br>I=
9;m aware of that. My point was that you didn't show what that looked l=
ike. What code do I have to write to do that, to specify where that "s=
uffix of the current call stack" is?<br></div></div></blockquote><div>=
<br>context foo_ctx(context caller, args){<br>// async function implementat=
ion here<br>}<br><br>future<T> foo(args...)<br>{<br>=C2=A0=C2=A0=C2=
=A0=C2=A0 return async(foo_ctx);<br>}<br>=C2=A0</div><div>as an end user of=
an async function you do not necessarily need to know. The function itself=
may setup the capture and restoring, although, for composition it is usefu=
l to both expose an opaque future returning function (foo) and an explicit =
context passing one for composition (foo_ctx). The former is implemented in=
therm of the latter with a library combinator (I'm calling it async he=
re as it conceptually the same as async for threads).<br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>I'm sure you could wrap this in some kind of ob=
ject. A `context_task<int(int)>`, which represents the ability to sta=
rt and resume a function that returns a value via promise/future, but that =
function gets executed in a context.<br><br>But `co_await` doesn't need=
to do that. It creates this machinery behind the scenes. And that's th=
e whole point of `co_await`: you don't have to create the machinery you=
rself.<br></div></div></blockquote><div><br>yes, you need to wrap bar in a =
new context; the only difference is that you do it by wrapping it with some=
library function instead of hardcoding the exact strategy using the keywor=
d await. The final client of foo doesn't need to know the details, they=
are simply invoking a future-returning function; whether it is implemented=
via manual continuation chaining, await magic or context is an implementat=
ion detail.<br></div></div></blockquote><div><br>My point is that, with `ex=
ecution_context`, there must be some form of code between the code receivin=
g the future-like thing and the `bar` function which actually "awaits&=
quot;, something else has to live. With `co_await`, no such code is <i>visi=
ble</i> to the user. The fact that this code is hidden is the primary advan=
tage of `co_await`, one which `execution_context` as a pure library feature=
cannot match.<br></div></div></blockquote><div><br>The code can be hidden =
inside bar itself (by either splitting it in a bar + bar_ctx or with an emb=
edded lambda.<br></div></div></blockquote><div><br>Regardless of which side=
it is on, there has to be a layer between the caller who gets a future and=
the actual resumable function providing that value.<br>=C2=A0</div><blockq=
uote 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><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>`co_awai=
t` is most certainly not a generic solution to the "coroutine" pr=
oblem. But in its primary domain, as a solution for basic function continua=
tions, it's <i>really</i> hard to beat in terms of overall code clarity=
..<br></div></div></blockquote><div><br>I do not necessarily disagree (excep=
t that noticing that co_await is anything but simple to understand and, wor=
st, most of the moving parts are hidden under compiler magic).</div></div><=
/blockquote><div><br>It's really simple to understand... so long as you=
never, <i>ever</i> have to write an await-able type, a future type, or any=
thing remotely related to them. As a client of some existing machinery, it&=
#39;s great.<br><br>The guts however are the stuff of nightmares. I really =
think there's a simpler language feature trying desperately to get out =
from under `co_await`'s vast machinery. And I think the over-complicate=
d nature of it comes from trying to handle things it really has no business=
trying to handle (like generators with `co_yield` and so forth).<br><br>Sp=
eaking of generators, does the more modern `execution_context` system have =
some way of handling generators in a way that permits guaranteed elision? I=
f not, that sounds like a great place for some kind of language feature, ev=
en if it gets tied into a library to do the actual suspension/resumption.<b=
r></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8ce1d3db-7fd0-4bb2-9871-e0f7e83a0010%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8ce1d3db-7fd0-4bb2-9871-e0f7e83a0010=
%40isocpp.org</a>.<br />
------=_Part_2670_564983418.1481060594638--
------=_Part_2669_1589685125.1481060594638--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Tue, 6 Dec 2016 14:50:40 -0800 (PST)
Raw View
------=_Part_2690_1350114503.1481064640369
Content-Type: multipart/alternative;
boundary="----=_Part_2691_27139352.1481064640369"
------=_Part_2691_27139352.1481064640369
Content-Type: text/plain; charset=UTF-8
On Tuesday, December 6, 2016 at 9:43:14 PM UTC, Nicol Bolas wrote:
[...]
> I really think there's a simpler language feature trying desperately to
> get out from under `co_await`'s vast machinery. And I think the
> over-complicated nature of it comes from trying to handle things it really
> has no business trying to handle (like generators with `co_yield` and so
> forth).
>
> Speaking of generators, does the more modern `execution_context` system
> have some way of handling generators in a way that permits guaranteed
> elision? If not, that sounds like a great place for some kind of language
> feature, even if it gets tied into a library to do the actual
> suspension/resumption.
>
I like to think that execution_context is that feature: it is a direct
realization of (one-shot, delimited) continuation and is a very powerful
and general abstraction.
Regarding optimizations a pure library based implementation of
execution_context will always require allocation and the compiler will be
prevented from doing any cross-context-switch analysis (including
inlining). It can still be very efficient (my current prof of concept is
capable of a context switch per clock cycle), but nowhere close to what is
possible with full compiler help.
In a compiler aided implementation, using intrinsics, full elision of all
allocations can be done in two steps:
1) first the compiler must prove that a single stack frame of statically
known size is enough instead of a full dedicated stack.
2) then the compiler must prove that the single stack frame can be
allocated in the caller stack.
The 2 step is obviously the same as for the co_await model: it can be done
as long as the compiler can track exactly the lifetime of child
execution_context object, which requires that the object does not the
escape.
Turns out that the exact same analysis is needed for step 1 as well: as
long as the execution_context object representing the parent also does not
escape, the compiler can prove an upper bound on the state that need to be
suspended [1] [2].
Similarly, when the compiler can see all uses of a context object, it can
exactly track each context switch target and completely remove the context
switch overhead.
Now, the problem, and also my issue with co_await, is that in C++ any
escape analysis based optimization is very fragile: it is very easy for an
object to escape: for example if the address of the containing object
escapes or even of a sibling member. As such, high performance/low latency
code can't easily relay on it, so we need a way to help the compiler.
We need some sort of optional annotation for execution_context, something
that would make the compiler only allow moving such an object to another
automatic variable or parameter to an inline function and assigning its
address only to similarly annotated variables. This annotation should also
implicitly propagate to containing objects and be deduced by template
deduction. It seems to me that it would look not completely unlike the
lifetime annotations in Rust or in the C++ Core Guidelines.
[1] Any function called from the child context can potentially context
switch away, but as long as the parent context does not escape, that
context is guaranteed not to be resumed during the call, so its stack can
be used for those calls instead of requiring a dedicated child stack. As a
simple proof, on a system implementing both, you would be allowed to call a
function that uses execution_context from a function using co_await without
any issues; in fact, as the parent context is not first class in the
co_await model, the non-escape proof is trivial.
[2] Calls to inline functions that take an execution context parameter must
also be proven to be non-recursive; but this specific analysis is also
required for constexpr evaluation, so is something that compilers know how
to do it.
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c954a066-ff4a-4ea6-9d70-b479812f8cf0%40isocpp.org.
------=_Part_2691_27139352.1481064640369
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, December 6, 2016 at 9:43:14 PM UTC, Nicol Bola=
s wrote:<br>[...]<br><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">=C2=A0I really think there's a simpler language feature trying=
desperately to get out from under `co_await`'s vast machinery. And I t=
hink the over-complicated nature of it comes from trying to handle things i=
t really has no business trying to handle (like generators with `co_yield` =
and so forth).<br><div><br>Speaking of generators, does the more modern `ex=
ecution_context` system have some way of handling generators in a way that =
permits guaranteed elision? If not, that sounds like a great place for some=
kind of language feature, even if it gets tied into a library to do the ac=
tual suspension/resumption.<br></div></div></blockquote><div><br>I like to =
think that execution_context is that feature: it is a direct realization of=
(one-shot, delimited) continuation and is a very powerful and general abst=
raction.<br><br>Regarding optimizations a pure library based implementation=
of execution_context will always require allocation and the compiler will =
be prevented from doing any cross-context-switch analysis (including inlini=
ng). It can still be very efficient (my current prof of concept is capable =
of a context switch per clock cycle), but nowhere close to what is possible=
with full compiler help.<br><br>In a compiler aided implementation, using =
intrinsics, full elision of all allocations can be done in two steps: <br><=
br>1) first the compiler must prove that a single stack frame of statically=
known size is enough instead of a full dedicated stack.<br>2) then the com=
piler must prove that the single stack frame can be allocated in the caller=
stack.<br><br>The 2 step is obviously the same as for the co_await model: =
it can be done as long as the compiler can track exactly the lifetime of ch=
ild execution_context object, which requires that the object does not the e=
scape. <br><br>Turns out that the exact same analysis is needed for step 1 =
as well: as long as the execution_context object representing the parent al=
so does not escape, the compiler can prove an upper bound on the state that=
need to be suspended [1] [2].<br><br>Similarly, when the compiler can see =
all uses of a context object, it can exactly track each context switch targ=
et and completely remove the context switch overhead.<br><br>Now, the probl=
em, and also my issue with co_await, is that in C++ any escape analysis bas=
ed optimization is very fragile: it is very easy for an object to escape: f=
or example if the address of the containing object escapes or even of a sib=
ling member. As such, high performance/low latency code can't easily re=
lay on it, so we need a way to help the compiler.<br><br>We need some sort =
of optional annotation for execution_context, something that would make the=
compiler only allow moving such an object to another automatic variable or=
parameter to an inline function and assigning its address only to similarl=
y annotated variables. This annotation should also implicitly propagate to =
containing objects and be deduced by template deduction. It seems to me tha=
t it would look not completely unlike the lifetime annotations in Rust or i=
n the C++ Core Guidelines.<br><br>[1] Any function called from the child co=
ntext can potentially context switch away, but as long as the parent contex=
t does not escape, that context is guaranteed not to be resumed during the =
call, so its stack can be used for those calls instead of requiring a dedic=
ated child stack. As a simple proof, on a system implementing both, you wou=
ld be allowed to call a function that uses execution_context from a functio=
n using co_await without any issues; in fact, as the parent context is not =
first class in the co_await model, the non-escape proof is trivial.<br><br>=
[2] Calls to inline functions that take an execution context parameter must=
also be proven to be non-recursive; but this specific analysis is also req=
uired for constexpr evaluation, so is something that compilers know how to =
do it.<br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c954a066-ff4a-4ea6-9d70-b479812f8cf0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c954a066-ff4a-4ea6-9d70-b479812f8cf0=
%40isocpp.org</a>.<br />
------=_Part_2691_27139352.1481064640369--
------=_Part_2690_1350114503.1481064640369--
.