------=_Part_10017_722292511.1487780099541
Content-Type: multipart/alternative;
 boundary="----=_Part_10018_2951393.1487780099541"

------=_Part_10018_2951393.1487780099541
Content-Type: text/plain; charset=UTF-8

So, the successor to P0099 (coroutines via library) is P0534, which
basically renamed a bunch of things and used a naming convention similar to
other language's APIs.

I think there is a concept that has been missing from many of the more
recent papers: local stacks.

Consider generator-type coroutines. They will exist entirely within the
local scope of the function that created them. They do need some stack
space but probably not a huge amount. And that stack space will be gone
once the local scope is gone.

P0057 recognizes this possibility and... well, essentially hopes that the
compiler can detect such uses and optimize away any stack allocations that
the system would otherwise require.

For P0534, what I would like to see is the ability to essentially force a
coroutine to use a stack that is part of the local context of the coroutine
that executed `std::callcc`. In code, it might look like this:

void func()
{
  std::local_stack space;

  std::continuation c = std::callcc(space, []() {...});
  for(auto val : std::generator<int>(std::move(c)))
  {
    //do stuff
  }
}

Essentially, `local_stack` does `alloca` for a reasonable size of space.
You can then shove that into `std::callcc`, which will use that space as
its stack.

Of course, the continuation cannot exceed the lifetime of `space`. And
`std::local_stack` would be neither copyable nor moveable, since it is
fundamentally bound to the site of its construction. Also, it's something
that you should not be able to create in any dynamic way (and possibly not
even as a class member), which would require compiler magic to guarantee.

With such a feature in place, the already fast performance of P0534 can
compete with P0057 in the case of using generators and the like. But unlike
P0057, it would have none of the restrictions about when and where it could
yield the generated value.

Granted, it would have its own restrictions, since yielding requires
accessing the caller's `continuation`. So if you want to yield in something
other than the root continuation function, you have to find a way to pass
the destination `continuation` to the code that needs to yield.

--
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/883aa1e2-0bcf-486a-8ac8-d9d93aa841a8%40isocpp.org.

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

<div dir=3D"ltr">So, the successor to P0099 (coroutines via library) is P05=
34, which basically renamed a bunch of things and used a naming convention =
similar to other language&#39;s APIs.<br><br>I think there is a concept tha=
t has been missing from many of the more recent papers: local stacks.<br><b=
r>Consider generator-type coroutines. They will exist entirely within the l=
ocal scope of the function that created them. They do need some stack space=
 but probably not a huge amount. And that stack space will be gone once the=
 local scope is gone.<br><br>P0057 recognizes this possibility and... well,=
 essentially hopes that the compiler can detect such uses and optimize away=
 any stack allocations that the system would otherwise require.<br><br>For =
P0534, what I would like to see is the ability to essentially force a corou=
tine to use a stack that is part of the local context of the coroutine that=
 executed `std::callcc`. In code, it might look like this:<br><br><div styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">local_stack space</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br>=C2=A0 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">continuation c </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">callcc</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">space</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[]()</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{...});</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">for</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> val </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">generator</span><span sty=
le=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">move</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">c</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">)))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//d=
o stuff</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></=
div><br>Essentially, `local_stack` does `alloca` for a reasonable size of s=
pace. You can then shove that into `std::callcc`, which will use that space=
 as its stack.<br><br>Of course, the continuation cannot exceed the lifetim=
e of `space`. And `std::local_stack` would be neither copyable nor moveable=
, since it is fundamentally bound to the site of its construction. Also, it=
&#39;s something that you should not be able to create in any dynamic way (=
and possibly not even as a class member), which would require compiler magi=
c to guarantee.<br><br>With such a feature in place, the already fast perfo=
rmance of P0534 can compete with P0057 in the case of using generators and =
the like. But unlike P0057, it would have none of the restrictions about wh=
en and where it could yield the generated value.<br><br>Granted, it would h=
ave its own restrictions, since yielding requires accessing the caller&#39;=
s `continuation`. So if you want to yield in something other than the root =
continuation function, you have to find a way to pass the destination `cont=
inuation` to the code that needs to yield.</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/883aa1e2-0bcf-486a-8ac8-d9d93aa841a8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/883aa1e2-0bcf-486a-8ac8-d9d93aa841a8=
%40isocpp.org</a>.<br />

------=_Part_10018_2951393.1487780099541--

------=_Part_10017_722292511.1487780099541--

.

--f403045c648257d97f05492164e2
Content-Type: text/plain; charset=UTF-8

2017-02-22 17:14 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:

> For P0534, what I would like to see is the ability to essentially force a
> coroutine to use a stack that is part of the local context of the coroutine
> that executed `std::callcc`. In code, it might look like this:
>
> void func()
> {
>   std::local_stack space;
>
>   std::continuation c = std::callcc(space, []() {...});
>   for(auto val : std::generator<int>(std::move(c)))
>   {
>     //do stuff
>   }
> }
>
> Essentially, `local_stack` does `alloca` for a reasonable size of space.
> You can then shove that into `std::callcc`, which will use that space as
> its stack.
>

well that's already possible - std::local_stack would be a stack-allocator.
the stack-allocator concept is not described in P0534 in detail but you
could take a look at boost.context which provides stack-allocators like
segmented-stack (stack grows on demand) or protected-fixedsize-stack (guard
page at the end).


> So if you want to yield in something other than the root continuation
> function, you have to find a way to pass the destination `continuation` to
> the code that needs to yield.
>

because it provides symmetric context switching (e.g. switch to arbitrary
other context, that has to explicitly specified)

--
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%2Bwfc181CC-YiDkhhge6B1qzfi8Hrk7zCwKsLHz15jz5D9axRQ%40mail.gmail.com.

--f403045c648257d97f05492164e2
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">2017=
-02-22 17:14 GMT+01:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank"><span class=3D"" style=3D"" id=3D":1=
rd.8" tabindex=3D"-1">jmckesson</span>@gmail.com</a>&gt;</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">For P0534, what I would like to se=
e is the ability to essentially force a coroutine to use a stack that is pa=
rt of the local context of the coroutine that executed `std::callcc`. In co=
de, it might look 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"m_-4945511419568294521prettyprint"><code class=3D"m_-494551141956=
8294521prettyprint"><div class=3D"m_-4945511419568294521subprettyprint"><sp=
an style=3D"color:#008" class=3D"m_-4945511419568294521styled-by-prettify">=
void</span><span style=3D"color:#000" class=3D"m_-4945511419568294521styled=
-by-prettify"> func</span><span style=3D"color:#660" class=3D"m_-4945511419=
568294521styled-by-prettify">()</span><span style=3D"color:#000" class=3D"m=
_-4945511419568294521styled-by-prettify"><br></span><span style=3D"color:#6=
60" class=3D"m_-4945511419568294521styled-by-prettify">{</span><span style=
=3D"color:#000" class=3D"m_-4945511419568294521styled-by-prettify"><br>=C2=
=A0 std</span><span style=3D"color:#660" class=3D"m_-4945511419568294521sty=
led-by-prettify">::</span><span style=3D"color:#000" class=3D"m_-4945511419=
568294521styled-by-prettify">local_stack space</span><span style=3D"color:#=
660" class=3D"m_-4945511419568294521styled-by-prettify">;</span><span style=
=3D"color:#000" class=3D"m_-4945511419568294521styled-by-prettify"><br><br>=
=C2=A0 std</span><span style=3D"color:#660" class=3D"m_-4945511419568294521=
styled-by-prettify">::</span><span style=3D"color:#000" class=3D"m_-4945511=
419568294521styled-by-prettify">continuation c </span><span style=3D"color:=
#660" class=3D"m_-4945511419568294521styled-by-prettify">=3D</span><span st=
yle=3D"color:#000" class=3D"m_-4945511419568294521styled-by-prettify"> std<=
/span><span style=3D"color:#660" class=3D"m_-4945511419568294521styled-by-p=
rettify">::</span><span style=3D"color:#000" class=3D"m_-494551141956829452=
1styled-by-prettify">callcc</span><span style=3D"color:#660" class=3D"m_-49=
45511419568294521styled-by-prettify">(</span><span style=3D"color:#000" cla=
ss=3D"m_-4945511419568294521styled-by-prettify">space</span><span style=3D"=
color:#660" class=3D"m_-4945511419568294521styled-by-prettify">,</span><spa=
n style=3D"color:#000" class=3D"m_-4945511419568294521styled-by-prettify"> =
</span><span style=3D"color:#660" class=3D"m_-4945511419568294521styled-by-=
prettify">[]()</span><span style=3D"color:#000" class=3D"m_-494551141956829=
4521styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_-4945=
511419568294521styled-by-prettify">{...});</span><span style=3D"color:#000"=
 class=3D"m_-4945511419568294521styled-by-prettify"><br>=C2=A0 </span><span=
 style=3D"color:#008" class=3D"m_-4945511419568294521styled-by-prettify">fo=
r</span><span style=3D"color:#660" class=3D"m_-4945511419568294521styled-by=
-prettify">(</span><span style=3D"color:#008" class=3D"m_-49455114195682945=
21styled-by-prettify">auto</span><span style=3D"color:#000" class=3D"m_-494=
5511419568294521styled-by-prettify"> val </span><span style=3D"color:#660" =
class=3D"m_-4945511419568294521styled-by-prettify">:</span><span style=3D"c=
olor:#000" class=3D"m_-4945511419568294521styled-by-prettify"> std</span><s=
pan style=3D"color:#660" class=3D"m_-4945511419568294521styled-by-prettify"=
>::</span><span style=3D"color:#000" class=3D"m_-4945511419568294521styled-=
by-prettify">generator</span><span style=3D"color:#080" class=3D"m_-4945511=
419568294521styled-by-prettify">&lt;int&gt;</span><span style=3D"color:#660=
" class=3D"m_-4945511419568294521styled-by-prettify">(</span><span style=3D=
"color:#000" class=3D"m_-4945511419568294521styled-by-prettify">std</span><=
span style=3D"color:#660" class=3D"m_-4945511419568294521styled-by-prettify=
">::</span><span style=3D"color:#000" class=3D"m_-4945511419568294521styled=
-by-prettify">move</span><span style=3D"color:#660" class=3D"m_-49455114195=
68294521styled-by-prettify">(</span><span style=3D"color:#000" class=3D"m_-=
4945511419568294521styled-by-prettify"><wbr>c</span><span style=3D"color:#6=
60" class=3D"m_-4945511419568294521styled-by-prettify">)))</span><span styl=
e=3D"color:#000" class=3D"m_-4945511419568294521styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color:#660" class=3D"m_-4945511419568294521styled=
-by-prettify">{</span><span style=3D"color:#000" class=3D"m_-49455114195682=
94521styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#800=
" class=3D"m_-4945511419568294521styled-by-prettify">//do stuff</span><span=
 style=3D"color:#000" class=3D"m_-4945511419568294521styled-by-prettify"><b=
r>=C2=A0 </span><span style=3D"color:#660" class=3D"m_-4945511419568294521s=
tyled-by-prettify">}</span><span style=3D"color:#000" class=3D"m_-494551141=
9568294521styled-by-prettify"><br></span><span style=3D"color:#660" class=
=3D"m_-4945511419568294521styled-by-prettify">}</span><span style=3D"color:=
#000" class=3D"m_-4945511419568294521styled-by-prettify"><br></span></div><=
/code></div><br>Essentially, `local_stack` does `alloca` for a reasonable s=
ize of space. You can then shove that into `std::callcc`, which will use th=
at space as its stack.<br></div></blockquote><div><br></div><div>well that&=
#39;s already possible - std::local_stack would be a stack-allocator. the s=
tack-allocator concept is not described in P0534 in detail but you could ta=
ke a look at boost.context which provides stack-allocators like segmented-s=
tack (stack grows on demand) or protected-<span class=3D"" style=3D"" id=3D=
":1rd.9" tabindex=3D"-1">fixedsize</span>-stack (guard page at the end).<br=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So =
if you want to yield in something other than the root continuation function=
, you have to find a way to pass the destination `continuation` to the code=
 that needs to yield.<br></div></blockquote></div><br></div><div class=3D"g=
mail_extra">because it provides symmetric context switching (e.g. switch to=
 arbitrary other context, that has to explicitly specified)<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc181CC-YiDkhhge6B1qzfi8Hrk7zCw=
KsLHz15jz5D9axRQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc181CC-Y=
iDkhhge6B1qzfi8Hrk7zCwKsLHz15jz5D9axRQ%40mail.gmail.com</a>.<br />

--f403045c648257d97f05492164e2--

.

------=_Part_1900_310587762.1487784033666
Content-Type: multipart/alternative;
 boundary="----=_Part_1901_431222783.1487784033666"

------=_Part_1901_431222783.1487784033666
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 22, 2017 at 11:57:31 AM UTC-5, Oliver Kowalke wrote:
>
> 2017-02-22 17:14 GMT+01:00 Nicol Bolas <jmckesson@gmail.com <javascript:>>
> :
>
>> For P0534, what I would like to see is the ability to essentially force a
>> coroutine to use a stack that is part of the local context of the coroutine
>> that executed `std::callcc`. In code, it might look like this:
>>
>> void func()
>> {
>>   std::local_stack space;
>>
>>   std::continuation c = std::callcc(space, []() {...});
>>   for(auto val : std::generator<int>(std::move(c)))
>>   {
>>     //do stuff
>>   }
>> }
>>
>> Essentially, `local_stack` does `alloca` for a reasonable size of space.
>> You can then shove that into `std::callcc`, which will use that space as
>> its stack.
>>
>
> well that's already possible - std::local_stack would be a
> stack-allocator. the stack-allocator concept is not described in P0534 in
> detail but you could take a look at boost.context which provides
> stack-allocators like segmented-stack (stack grows on demand) or protected-
> fixedsize-stack (guard page at the end).
>

I'm not asking for it to merely be possible. I'm asking for it to be a
first-class part of the feature itself.

Implementing it yourself would require very explicit knowledge of platform
requirements for stacks, like alignments, sizes, guard pages, and so forth.
Not to mention the fact that `alloca` is *not* a standard library function,
so any implementation would necessarily be platform specific.

This is a tool that every implementation of this system should have. It's a
tool that everyone should be able to rely upon to make light-weight
generators and so forth. It isn't something everyone should have to
implement across their platforms of choice.

And most importantly, it is a tool that strips P0057 of one of its biggest
performance wins over P0534. And anything that does *that* is
self-justifying in my book ;)

--
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/dee10a65-a29f-4b3d-aefb-ac3fb1f49093%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, February 22, 2017 at 11:57:31 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">2017-02-22 17:14 GMT+01:00 Nico=
l Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"XBakx9FOBwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;"><span>jmckesson</span>@gmail.com</a>&gt;</span>:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">For P0534, what I would l=
ike to see is the ability to essentially force a coroutine to use a stack t=
hat is part of the local context of the coroutine that executed `std::callc=
c`. In code, it might look like this:<br><br><div style=3D"background-color=
:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-w=
idth:1px"><code><div><span style=3D"color:#008">void</span><span style=3D"c=
olor:#000"> func</span><span style=3D"color:#660">()</span><span style=3D"c=
olor:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"col=
or:#000"><br>=C2=A0 std</span><span style=3D"color:#660">::</span><span sty=
le=3D"color:#000">local_stack space</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"><br><br>=C2=A0 std</span><span style=3D"color:=
#660">::</span><span style=3D"color:#000">continuation c </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">callcc</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">space</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">[]()</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">{...});</span><span style=3D"color:#000"><br>=C2=A0 </span><span s=
tyle=3D"color:#008">for</span><span style=3D"color:#660">(</span><span styl=
e=3D"color:#008">auto</span><span style=3D"color:#000"> val </span><span st=
yle=3D"color:#660">:</span><span style=3D"color:#000"> std</span><span styl=
e=3D"color:#660">::</span><span style=3D"color:#000">generator</span><span =
style=3D"color:#080">&lt;int&gt;</span><span style=3D"color:#660">(</span><=
span style=3D"color:#000">std</span><span style=3D"color:#660">::</span><sp=
an style=3D"color:#000">move</span><span style=3D"color:#660">(</span><span=
 style=3D"color:#000"><wbr>c</span><span style=3D"color:#660">)))</span><sp=
an style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#800">//do stuff</span><span style=3D"color:#000"><br>=C2=A0 </span><span s=
tyle=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div></cod=
e></div><br>Essentially, `local_stack` does `alloca` for a reasonable size =
of space. You can then shove that into `std::callcc`, which will use that s=
pace as its stack.<br></div></blockquote><div><br></div><div>well that&#39;=
s already possible - std::local_stack would be a stack-allocator. the stack=
-allocator concept is not described in P0534 in detail but you could take a=
 look at boost.context which provides stack-allocators like segmented-stack=
 (stack grows on demand) or protected-<span>fixedsize</span>-stack (guard p=
age at the end).<br></div></div></div></div></blockquote><div><br>I&#39;m n=
ot asking for it to merely be possible. I&#39;m asking for it to be a first=
-class part of the feature itself.<br><br>Implementing it yourself would re=
quire very explicit knowledge of platform requirements for stacks, like ali=
gnments, sizes, guard pages, and so forth. Not to mention the fact that `al=
loca` is <i>not</i> a standard library function, so any implementation woul=
d necessarily be platform specific.<br><br>This is a tool that every implem=
entation of this system should have. It&#39;s a tool that everyone should b=
e able to rely upon to make light-weight generators and so forth. It isn&#3=
9;t something everyone should have to implement across their platforms of c=
hoice.<br><br>And most importantly, it is a tool that strips P0057 of one o=
f its biggest performance wins over P0534. And anything that does <i>that</=
i> is self-justifying in my book ;)</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dee10a65-a29f-4b3d-aefb-ac3fb1f49093%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dee10a65-a29f-4b3d-aefb-ac3fb1f49093=
%40isocpp.org</a>.<br />

------=_Part_1901_431222783.1487784033666--

------=_Part_1900_310587762.1487784033666--

.

--001a11c047142f5fbd0549225951
Content-Type: text/plain; charset=UTF-8

2017-02-22 18:20 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:

> I'm not asking for it to merely be possible. I'm asking for it to be a
> first-class part of the feature itself.
>

I'm not sure what you mean with 'first-class' part. I assume that you want
to see local_stack added to the list of pre-defined stack-allocators (like
protected_fixedsize_stack and segemented_stack).


> Implementing it yourself would require very explicit knowledge of platform
> requirements for stacks,
>

I'd like to point out that you have the possiblility to implement and use
your own stack-allocator  - for instance a stack-allocator that caches and
reuses stacks.

--
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%2Bwfc18q0L7Ch_LZkTxY6k1-wZndBUTPT29F5gP5TLCso26s%3DQ%40mail.gmail.com.

--001a11c047142f5fbd0549225951
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">2017=
-02-22 18:20 GMT+01:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:=
jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D""></span>=
<div>I&#39;m not asking for it to merely be possible. I&#39;m asking for it=
 to be a first-class part of the feature itself.<br></div></div></blockquot=
e><div><br></div><div>I&#39;m not sure what you mean with &#39;first-class&=
#39; part. I assume that you want to see local_stack added to the list of p=
re-defined stack-allocators (like protected_fixedsize_stack and segemented_=
stack).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Implementing it yourself would require very explicit knowledg=
e of platform requirements for stacks,<br></div></div></blockquote><div><br=
></div>I&#39;d like to point out that you have the possiblility to implemen=
t and use your own stack-allocator=C2=A0 - for instance a stack-allocator t=
hat caches and reuses stacks.<br></div><br></div><div class=3D"gmail_extra"=
><br></div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18q0L7Ch_LZkTxY6k1-wZndBUTPT2=
9F5gP5TLCso26s%3DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18q0L=
7Ch_LZkTxY6k1-wZndBUTPT29F5gP5TLCso26s%3DQ%40mail.gmail.com</a>.<br />

--001a11c047142f5fbd0549225951--

.

------=_Part_782_419438123.1487788930122
Content-Type: multipart/alternative;
 boundary="----=_Part_783_1822335205.1487788930122"

------=_Part_783_1822335205.1487788930122
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 22, 2017 at 1:05:59 PM UTC-5, Oliver Kowalke wrote:
>
> 2017-02-22 18:20 GMT+01:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> I'm not asking for it to merely be possible. I'm asking for it to be a
>> first-class part of the feature itself.
>>
>
> I'm not sure what you mean with 'first-class' part. I assume that you want
> to see local_stack added to the list of pre-defined stack-allocators (like
> protected_fixedsize_stack and segemented_stack).
>

Yes, that's the idea. Whether it uses `alloca` or an internal
`aligned_storage` buffer of the appropriate type is up to it. But I'd like
to see it take its size as a template parameter, with an
implementation-defined default. Oh, and having a `protected_` version would
be great too.

After spending some time looking at Boost.Context 1.63's
<http://www.boost.org/doc/libs/1_63_0/libs/context/doc/html/context/stack.html>
stack allocators, there are a couple of things that are unclear and some
others that I think can be improved.

For example, it's not clear where `stack_traits` comes from. It seems to me
that those are just a set of compile-time constants. So making those
functions `constexpr` (or even better, just `constexpr` static variables)
would be a really good idea. It also makes a lot of sense for
`basic_(protected_)fixedsize_stack` to take its size as a template
parameter rather than a constructor parameter. After all, I highly doubt
people are going to be using runtime computations to determine the size of
the stack, since the `stack_traits` functions are all compile-time
constants. By making the size a template parameter, you can detect such
errors at compile time.

Of course, you could always take the `gsl::span` approach and have
specializations that take the size as a template parameter or as a runtime
constructor parameter.

Implementing it yourself would require very explicit knowledge of platform
>> requirements for stacks,
>>
>
> I'd like to point out that you have the possiblility to implement and use
> your own stack-allocator  - for instance a stack-allocator that caches and
> reuses stacks.
>

Do we? P0534 says:

> This concept, along with std::callcc() accepting std::allocator_arg_t, *is
an optional part of the proposal*. It might be that implementations can
reliably infer the optimal stack representation.

By "This concept", I assume it means the StackAllocator concept, as defined
above. Without having such a concept, how would users be able to create
their own allocators?

Oh sure, we could have a pool of `fixedsize_stack` objects. But such a pool
wouldn't be a StackAllocator; it would just have functions to extract new
stack and put finished ones back in the pool.

Are StackAllocators optional parts of this feature or mandatory features?

--
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/9383f8a2-e150-413f-ac6e-06ee2e5197bb%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, February 22, 2017 at 1:05:59 PM UTC-5, Olive=
r 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"lt=
r"><div><div class=3D"gmail_quote">2017-02-22 18:20 GMT+01:00 Nicol Bolas <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"qcjKNY5SBwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">jmck...@gmail.com</a>&gt;</span>:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><span></span><div>I&#39;m not asking for it to me=
rely be possible. I&#39;m asking for it to be a first-class part of the fea=
ture itself.<br></div></div></blockquote><div><br></div><div>I&#39;m not su=
re what you mean with &#39;first-class&#39; part. I assume that you want to=
 see local_stack added to the list of pre-defined stack-allocators (like pr=
otected_fixedsize_stack and segemented_stack).</div></div></div></div></blo=
ckquote><div><br>Yes, that&#39;s the idea. Whether it uses `alloca` or an i=
nternal `aligned_storage` buffer of the appropriate type is up to it. But I=
&#39;d like to see it take its size as a template parameter, with an implem=
entation-defined default. Oh, and having a `protected_` version would be gr=
eat too.<br><br>After spending some time looking at <a href=3D"http://www.b=
oost.org/doc/libs/1_63_0/libs/context/doc/html/context/stack.html">Boost.Co=
ntext 1.63&#39;s</a> stack allocators, there are a couple of things that ar=
e unclear and some others that I think can be improved.<br><br>For example,=
 it&#39;s not clear where `stack_traits` comes from. It seems to me that th=
ose are just a set of compile-time constants. So making those functions `co=
nstexpr` (or even better, just `constexpr` static variables) would be a rea=
lly good idea. It also makes a lot of sense for `basic_(protected_)fixedsiz=
e_stack` to take its size as a template parameter rather than a constructor=
 parameter. After all, I highly doubt people are going to be using runtime =
computations to determine the size of the stack, since the `stack_traits` f=
unctions are all compile-time constants. By making the size a template para=
meter, you can detect such errors at compile time.<br><br>Of course, you co=
uld always take the `gsl::span` approach and have specializations that take=
 the size as a template parameter or as a runtime constructor parameter.<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"><d=
iv><div class=3D"gmail_quote"><div> </div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>Implementing it yourself would require very explicit kn=
owledge of platform requirements for stacks,<br></div></div></blockquote><d=
iv><br></div>I&#39;d like to point out that you have the possiblility to im=
plement and use your own stack-allocator=C2=A0 - for instance a stack-alloc=
ator that caches and reuses stacks.<br></div></div></div></blockquote><div>=
<br>Do we? P0534 says:<br><br>&gt; This concept, along with std::callcc() a=
ccepting std::allocator_arg_t, <b>is an optional part of the proposal</b>. =
It might be that implementations can reliably infer the optimal stack repre=
sentation.<br><br>By &quot;This concept&quot;, I assume it means the StackA=
llocator concept, as defined above. Without having such a concept, how woul=
d users be able to create their own allocators?<br><br>Oh sure, we could ha=
ve a pool of `fixedsize_stack` objects. But such a pool wouldn&#39;t be a S=
tackAllocator; it would just have functions to extract new stack and put fi=
nished ones back in the pool.<br><br>Are StackAllocators optional parts of =
this feature or mandatory features?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9383f8a2-e150-413f-ac6e-06ee2e5197bb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9383f8a2-e150-413f-ac6e-06ee2e5197bb=
%40isocpp.org</a>.<br />

------=_Part_783_1822335205.1487788930122--

------=_Part_782_419438123.1487788930122--

.

------=_Part_2075_1615523810.1487792686169
Content-Type: multipart/alternative;
 boundary="----=_Part_2076_1712203087.1487792686169"

------=_Part_2076_1712203087.1487792686169
Content-Type: text/plain; charset=UTF-8

Also, another thought occurred to me.

P0534 has the concept of continuations that can only be executed on a
specific thread. Right now, this is restricted specifically to
system-created continuations (the context for the main thread and
subsidiary threads). But there are times when a user's `callcc` function
would be limited to a specific thread.

The reason for that would be for implementing yield. If you want to be able
to yield without having to pass the continuation to yield to, then you're
going to have to develop a system where continuing such a function puts the
continuation to yield to in some non-local memory. The most obvious place
would be a thread-local variable. To allow multiple nested generators, the
thread_local would be a stack.

But a thread-local variable is thread local. If one of them happens to get
executed in some other thread, then the stack of suspended coroutines will
be a completely different one.

So being able to launch a function such that continuing it on a different
thread is explicitly UB, in the same way as main/`std::thread` contexts,
would be a useful feature.

--
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/77fcff5e-b003-47a2-9848-ce204c2f51cb%40isocpp.org.

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

<div dir=3D"ltr">Also, another thought occurred to me.<br><br>P0534 has the=
 concept of continuations that can only be executed on a specific thread. R=
ight now, this is restricted specifically to system-created continuations (=
the context for the main thread and subsidiary threads). But there are time=
s when a user&#39;s `callcc` function would be limited to a specific thread=
..<br><br>The reason for that would be for implementing yield. If you want t=
o be able to yield without having to pass the continuation to yield to, the=
n you&#39;re going to have to develop a system where continuing such a func=
tion puts the continuation to yield to in some non-local memory. The most o=
bvious place would be a thread-local variable. To allow multiple nested gen=
erators, the thread_local would be a stack.<br><br>But a thread-local varia=
ble is thread local. If one of them happens to get executed in some other t=
hread, then the stack of suspended coroutines will be a completely differen=
t one.<br><br>So being able to launch a function such that continuing it on=
 a different thread is explicitly UB, in the same way as main/`std::thread`=
 contexts, would be a useful feature.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/77fcff5e-b003-47a2-9848-ce204c2f51cb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/77fcff5e-b003-47a2-9848-ce204c2f51cb=
%40isocpp.org</a>.<br />

------=_Part_2076_1712203087.1487792686169--

------=_Part_2075_1615523810.1487792686169--

.

------=_Part_665_196615820.1488276503836
Content-Type: multipart/alternative;
 boundary="----=_Part_666_1934338729.1488276503836"

------=_Part_666_1934338729.1488276503836
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 22, 2017 at 4:14:59 PM UTC, Nicol Bolas wrote:
>
> So, the successor to P0099 (coroutines via library) is P0534, which
> basically renamed a bunch of things and used a naming convention similar to
> other language's APIs.
>
> I think there is a concept that has been missing from many of the more
> recent papers: local stacks.
>
[...]

> For P0534, what I would like to see is the ability to essentially force a
> coroutine to use a stack that is part of the local context of the coroutine
> that executed `std::callcc`. In code, it might look like this:
>
>
Such a feature is unfortunately extremely dangerous: overflowing the local
stack would be completely silent and overwrite local variables (including
return addresses) [1].

Providing an easy to use interface to it in the standard would be
irresponsible.

We would be better off adding annotations to the language so that purely
scoped coroutine allocations can be embedded in the containing stack frame
by the compiler which can do it safely. The annotation would guarantee that
a continuation cannot be passed (by value or reference) to non-inline
functions or functions with unknown recursion upper bound [2].

it can be done purely as an optimization, but an annotation would guarantee
the optimization.

[1] Of course guard pages are always an option, but it would make creating
the local stack no faster than a proper stack.

[2] BTW, this is one of the reason I dislike the concept of a thread local
'default' yield target: it would prevent the compiler from making such an
analysis as every continuation will escape outside of compiler control.

--
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/3c0290be-5dc5-4add-9474-425ed085d5c8%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, February 22, 2017 at 4:14:59 PM UTC, Nicol B=
olas 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">So=
, the successor to P0099 (coroutines via library) is P0534, which basically=
 renamed a bunch of things and used a naming convention similar to other la=
nguage&#39;s APIs.<br><br>I think there is a concept that has been missing =
from many of the more recent papers: local stacks.</div></blockquote><div>[=
....] <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=
">For P0534, what I would like to see is the ability to essentially force a=
 coroutine to use a stack that is part of the local context of the coroutin=
e that executed `std::callcc`. In code, it might look like this:<br><br></d=
iv></blockquote><div><br>Such a feature is unfortunately extremely dangerou=
s: overflowing the local stack would be completely silent and overwrite loc=
al variables (including return addresses) [1]. <br><br>Providing an easy to=
 use interface to it in the standard would be irresponsible.<br><br>We woul=
d be better off adding annotations to the language so that purely scoped co=
routine allocations can be embedded in the containing stack frame by the co=
mpiler which can do it safely. The annotation would guarantee that a contin=
uation cannot be passed (by value or reference) to non-inline functions or =
functions with unknown recursion upper bound [2].<br><br>it can be done pur=
ely as an optimization, but an annotation would guarantee the optimization.=
<br><br>[1] Of course guard pages are always an option, but it would make c=
reating the local stack no faster than a proper stack.<br><br>[2] BTW, this=
 is one of the reason I dislike the concept of a thread local &#39;default&=
#39; yield target: it would prevent the compiler from making such an analys=
is as every continuation will escape outside of compiler control.<br></div>=
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c0290be-5dc5-4add-9474-425ed085d5c8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c0290be-5dc5-4add-9474-425ed085d5c8=
%40isocpp.org</a>.<br />

------=_Part_666_1934338729.1488276503836--

------=_Part_665_196615820.1488276503836--

.

------=_Part_8825_1780035485.1488299337656
Content-Type: multipart/alternative;
 boundary="----=_Part_8826_1432406894.1488299337656"

------=_Part_8826_1432406894.1488299337656
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 28, 2017 at 5:08:24 AM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Wednesday, February 22, 2017 at 4:14:59 PM UTC, Nicol Bolas wrote:
>>
>> So, the successor to P0099 (coroutines via library) is P0534, which
>> basically renamed a bunch of things and used a naming convention similar to
>> other language's APIs.
>>
>> I think there is a concept that has been missing from many of the more
>> recent papers: local stacks.
>>
> [...]
>
>> For P0534, what I would like to see is the ability to essentially force a
>> coroutine to use a stack that is part of the local context of the coroutine
>> that executed `std::callcc`. In code, it might look like this:
>>
>>
> Such a feature is unfortunately extremely dangerous: overflowing the local
> stack would be completely silent and overwrite local variables (including
> return addresses) [1].
>
> Providing an easy to use interface to it in the standard would be
> irresponsible.
>
> We would be better off adding annotations to the language so that purely
> scoped coroutine allocations can be embedded in the containing stack frame
> by the compiler which can do it safely. The annotation would guarantee that
> a continuation cannot be passed (by value or reference) to non-inline
> functions or functions with unknown recursion upper bound [2].
>

1) That requires a language feature, while P0534 is a pure-library
extension.

2) That's all new stuff of unknown complexity and nobody has implemented
anything remotely like it. By contrast, P0534 is a thing that exists right
now.

3) The restriction to inline functions makes it non-workable for general
purpose use, while the feature I suggest, no matter how dangerous, can work
with anything. Generality is what makes call/cc superior to most attempts
at a language feature for this.

it can be done purely as an optimization, but an annotation would guarantee
> the optimization.
>
> [1] Of course guard pages are always an option, but it would make creating
> the local stack no faster than a proper stack.
>

Why would having guard pages make it as slow as allocating a stack? Do
guard pages have to be dynamically allocated?

[2] BTW, this is one of the reason I dislike the concept of a thread local
> 'default' yield target: it would prevent the compiler from making such an
> analysis as every continuation will escape outside of compiler control.
>

--
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/0aed6acb-4103-4b94-ab71-7c4af23a0cc2%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, February 28, 2017 at 5:08:24 AM UTC-5, Giovann=
i Piero Deretta 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 Wednesday, February 22, 2017 at 4:14:59 PM UTC, Nicol Bolas wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So, the success=
or to P0099 (coroutines via library) is P0534, which basically renamed a bu=
nch of things and used a naming convention similar to other language&#39;s =
APIs.<br><br>I think there is a concept that has been missing from many of =
the more recent papers: local stacks.</div></blockquote><div>[...] <br></di=
v><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">For P0534, what =
I would like to see is the ability to essentially force a coroutine to use =
a stack that is part of the local context of the coroutine that executed `s=
td::callcc`. In code, it might look like this:<br><br></div></blockquote><d=
iv><br>Such a feature is unfortunately extremely dangerous: overflowing the=
 local stack would be completely silent and overwrite local variables (incl=
uding return addresses) [1].<br><br>Providing an easy to use interface to i=
t in the standard would be irresponsible.<br><br>We would be better off add=
ing annotations to the language so that purely scoped coroutine allocations=
 can be embedded in the containing stack frame by the compiler which can do=
 it safely. The annotation would guarantee that a continuation cannot be pa=
ssed (by value or reference) to non-inline functions or functions with unkn=
own recursion upper bound [2].<br></div></div></blockquote><div><br>1) That=
 requires a language feature, while P0534 is a pure-library extension.<br><=
br>2) That&#39;s all new stuff of unknown complexity and nobody has impleme=
nted anything remotely like it. By contrast, P0534 is a thing that exists r=
ight now.<br><br>3) The restriction to inline functions makes it non-workab=
le for general purpose use, while the feature I suggest, no matter how dang=
erous, can work with anything. Generality is what makes call/cc superior to=
 most attempts at a language feature for this.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>it can be done purely a=
s an optimization, but an annotation would guarantee the optimization.<br><=
br>[1] Of course guard pages are always an option, but it would make creati=
ng the local stack no faster than a proper stack.<br></div></div></blockquo=
te><div><br>Why would having guard pages make it as slow as allocating a st=
ack? Do guard pages have to be dynamically allocated?<br><br></div><blockqu=
ote 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>[2] BTW, this is=
 one of the reason I dislike the concept of a thread local &#39;default&#39=
; yield target: it would prevent the compiler from making such an analysis =
as every continuation will escape outside of compiler control.<br></div></d=
iv></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0aed6acb-4103-4b94-ab71-7c4af23a0cc2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0aed6acb-4103-4b94-ab71-7c4af23a0cc2=
%40isocpp.org</a>.<br />

------=_Part_8826_1432406894.1488299337656--

------=_Part_8825_1780035485.1488299337656--

.

------=_Part_1233_733486675.1488301819111
Content-Type: multipart/alternative;
 boundary="----=_Part_1234_579841805.1488301819111"

------=_Part_1234_579841805.1488301819111
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 28, 2017 at 4:28:57 PM UTC, Nicol Bolas wrote:
>
> On Tuesday, February 28, 2017 at 5:08:24 AM UTC-5, Giovanni Piero Deretta
> wrote:
>>
>> On Wednesday, February 22, 2017 at 4:14:59 PM UTC, Nicol Bolas wrote:
>>>
>>> So, the successor to P0099 (coroutines via library) is P0534, which
>>> basically renamed a bunch of things and used a naming convention similar to
>>> other language's APIs.
>>>
>>> I think there is a concept that has been missing from many of the more
>>> recent papers: local stacks.
>>>
>> [...]
>>
>>> For P0534, what I would like to see is the ability to essentially force
>>> a coroutine to use a stack that is part of the local context of the
>>> coroutine that executed `std::callcc`. In code, it might look like this:
>>>
>>>
>> Such a feature is unfortunately extremely dangerous: overflowing the
>> local stack would be completely silent and overwrite local variables
>> (including return addresses) [1].
>>
>> Providing an easy to use interface to it in the standard would be
>> irresponsible.
>>
>> We would be better off adding annotations to the language so that purely
>> scoped coroutine allocations can be embedded in the containing stack frame
>> by the compiler which can do it safely. The annotation would guarantee that
>> a continuation cannot be passed (by value or reference) to non-inline
>> functions or functions with unknown recursion upper bound [2].
>>
>
> 1) That requires a language feature, while P0534 is a pure-library
> extension.
>
> 2) That's all new stuff of unknown complexity and nobody has implemented
> anything remotely like it. By contrast, P0534 is a thing that exists right
> now.
>
> 3) The restriction to inline functions makes it non-workable for general
> purpose use, while the feature I suggest, no matter how dangerous, can work
> with anything. Generality is what makes call/cc superior to most attempts
> at a language feature for this.
>
>
P0534 will still show a pure library interface. The annotation would be
optional and only used to enable the optimization. Of course it would need
to be implemented first to prove that it works. It doesn't need to be part
of the initial proposal.

My problem is that local stacks are very, very dangerous as there is no way
to reliably estimate the stack size usage and the consequences are
disastrous (literally everything becomes a potential buffer overflow). So,
it is great that boost.context (and P0534) allows a determined programmer
to use it, but I don't think the standard should provide the loaded foot
gun in a nicely packaged box.

it can be done purely as an optimization, but an annotation would guarantee
>> the optimization.
>>
>> [1] Of course guard pages are always an option, but it would make
>> creating the local stack no faster than a proper stack.
>>
>
> Why would having guard pages make it as slow as allocating a stack? Do
> guard pages have to be dynamically allocated?
>

You need to manipulate the virtual memory mapping which requires an
expensive system call to the os (i.e. unmmap) which will dwarf the cost the
memory allocation itself.

In fact with dynamically allocated stacks you can have a free list of
recently used stacks with the guard pages already prepared but if you carve
a chunk of the existing stack you have to do the unmapping on the fly. The
other option is storing the current stack limit on some thread local
variable and checking it on every function call/stack frame allocation.
That's actually feasible and already provided as an option of some
platforms, but it adds a non negligible cost to every function call
(whether in a coroutine or not).


--
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/89d40a43-2397-4419-8c79-f20a0d4cedce%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, February 28, 2017 at 4:28:57 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 T=
uesday, February 28, 2017 at 5:08:24 AM UTC-5, Giovanni Piero Deretta 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 Wednesday, Feb=
ruary 22, 2017 at 4:14:59 PM UTC, Nicol Bolas wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">So, the successor to P0099 (coroutines vi=
a library) is P0534, which basically renamed a bunch of things and used a n=
aming convention similar to other language&#39;s APIs.<br><br>I think there=
 is a concept that has been missing from many of the more recent papers: lo=
cal stacks.</div></blockquote><div>[...] <br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">For P0534, what I would like to see is the=
 ability to essentially force a coroutine to use a stack that is part of th=
e local context of the coroutine that executed `std::callcc`. In code, it m=
ight look like this:<br><br></div></blockquote><div><br>Such a feature is u=
nfortunately extremely dangerous: overflowing the local stack would be comp=
letely silent and overwrite local variables (including return addresses) [1=
].<br><br>Providing an easy to use interface to it in the standard would be=
 irresponsible.<br><br>We would be better off adding annotations to the lan=
guage so that purely scoped coroutine allocations can be embedded in the co=
ntaining stack frame by the compiler which can do it safely. The annotation=
 would guarantee that a continuation cannot be passed (by value or referenc=
e) to non-inline functions or functions with unknown recursion upper bound =
[2].<br></div></div></blockquote><div><br>1) That requires a language featu=
re, while P0534 is a pure-library extension.<br><br></div></div></blockquot=
e><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>2) That&#39;s all new stuff of unknown complexity and nobody has imple=
mented anything remotely like it. By contrast, P0534 is a thing that exists=
 right now.<br><br>3) The restriction to inline functions makes it non-work=
able for general purpose use, while the feature I suggest, no matter how da=
ngerous, can work with anything. Generality is what makes call/cc superior =
to most attempts at a language feature for this.<br><br></div></div></block=
quote><div><br>P0534 will still show a pure library interface. The annotati=
on would be optional and only used to enable the optimization. Of course it=
 would need to be implemented first to prove that it works. It doesn&#39;t =
need to be part of the initial proposal.<br>=C2=A0<br>My problem is that lo=
cal stacks are very, very dangerous as there is no way to reliably estimate=
 the stack size usage and the consequences are disastrous (literally everyt=
hing becomes a potential buffer overflow). So, it is great that boost.conte=
xt (and P0534) allows a determined programmer to use it, but I don&#39;t th=
ink the standard should provide the loaded foot gun in a nicely packaged bo=
x.<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"lt=
r"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>it can be done purely as an optimization, but an annotation would guarante=
e the optimization.<br><br>[1] Of course guard pages are always an option, =
but it would make creating the local stack no faster than a proper stack.<b=
r></div></div></blockquote><div><br>Why would having guard pages make it as=
 slow as allocating a stack? Do guard pages have to be dynamically allocate=
d?</div></div></blockquote><div><br>You need to manipulate the virtual memo=
ry mapping which requires an expensive system call to the os (i.e. unmmap) =
which will dwarf the cost the memory allocation itself. <br><br>In fact wit=
h dynamically allocated stacks you can have a free list of recently used st=
acks with the guard pages already prepared but if you carve a chunk of the =
existing stack you have to do the unmapping on the fly. The other option is=
 storing the current stack limit on some thread local variable and checking=
 it on every function call/stack frame allocation. That&#39;s actually feas=
ible and already provided as an option of some platforms, but it adds a non=
 negligible cost to every function call (whether in a coroutine or not).<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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/89d40a43-2397-4419-8c79-f20a0d4cedce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/89d40a43-2397-4419-8c79-f20a0d4cedce=
%40isocpp.org</a>.<br />

------=_Part_1234_579841805.1488301819111--

------=_Part_1233_733486675.1488301819111--

.