------=_Part_500_10438480.1363369697705
Content-Type: text/plain; charset=ISO-8859-1

Hi,

this is the first version of the proposal to add coroutines to C++.
The pdf can be found here: http://ok73.funpic.de/coroutine.pdf

so long,
Oliver

--

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



------=_Part_500_10438480.1363369697705
Content-Type: text/html; charset=ISO-8859-1

Hi,<br><br>this is the first version of the proposal to add coroutines to C++.<br>The pdf can be found here: http://ok73.funpic.de/coroutine.pdf<br><br>so long,<br>Oliver<br><div style="display: none;" id="__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

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

------=_Part_500_10438480.1363369697705--

.

------=_Part_2_31464158.1363455808551
Content-Type: text/plain; charset=ISO-8859-1

I like it and I think that coroutines should be added to the standard.

A few questions though:

1. You say that this is a library only change but you require that it has a
stack that can grow on demand. As far as I know that can not currently be
implemented in C++. So that would not make this a library only change,
right? I think the requirement for growing stacks is a good one and we
should not drop it just to make this a library only change. It might be a
good idea to make the growing stack a separate class that is used by the
coroutine.
2. Why does the coroutine get called from the constructor? You say that
otherwise it is difficult to detect the completeness of a coroutine, but I
don't understand why that would be. Can you explain the std::distance
example you gave and why it wouldn't work if you created the coroutine in
one line and called operator() in the next?
3. Why does operator() return the coroutine itself? I could understand if
it returns the result (or a std::optional<result>) or void. But I don't see
why it would return the coroutine itself. I think it should return void,
because anything else is confusing. For example this will compile with
boosts coroutine implementation:
coroutine<bool ()> coro(/*...*/);
bool result = coro(); // doesn't actually assign the result of the
coroutine, but the current state instead
4. How does the coroutine unwind the stack on destruction? I believe that
in boost it's done by throwing an exception, which unwinds the stack from
the point where you last left the coroutine to where the exception is being
caught. Meaning if nobody catches that exception the stack is unwound all
the way, but that fails if there is a catch(...) block anywhere that
doesn't re-throw. I think it's a reasonable requirement to say that nobody
must have a catch(...) block that doesn't re-throw if you want stack
unwinding to work, but if the standard is to be changed, then this could be
made more robust. For example you could introduce a magical exception type
that automatically re-throws when caught, except when it's caught by
std::coroutine.

On Friday, March 15, 2013 1:48:17 PM UTC-4, Oliver Kowalke wrote:
>
> Hi,
>
> this is the first version of the proposal to add coroutines to C++.
> The pdf can be found here: http://ok73.funpic.de/coroutine.pdf
>
> so long,
> Oliver
>

--

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



------=_Part_2_31464158.1363455808551
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I like it and I think that coroutines should be added to the standard.<br><=
br>A few questions though:<br><br>1. You say that this is a library only ch=
ange but you require that it has a stack that can grow on demand. As far as=
 I know that can not currently be implemented in C++. So that would not mak=
e this a library only change, right? I think the requirement for growing st=
acks is a good one and we should not drop it just to make this a library on=
ly change. It might be a good idea to make the growing stack a separate cla=
ss that is used by the coroutine.<br>2. Why does the coroutine get called f=
rom the constructor? You say that otherwise it is difficult to detect the c=
ompleteness of a coroutine, but I don't understand why that would be. Can y=
ou explain the std::distance example you gave and why it wouldn't work if y=
ou created the coroutine in one line and called operator() in the next?<br>=
3. Why does operator() return the coroutine itself? I could understand if i=
t returns the result (or a std::optional&lt;result&gt;) or void. But I don'=
t see why it would return the coroutine itself. I think it should return vo=
id, because anything else is confusing. For example this will compile with =
boosts coroutine implementation:<br>coroutine&lt;bool ()&gt; coro(/*...*/);=
<br>bool result =3D coro(); // doesn't actually assign the result of the co=
routine, but the current state instead<br>4. How does the coroutine unwind =
the stack on destruction? I believe that in boost it's done by throwing an =
exception, which unwinds the stack from the point where you last left the c=
oroutine to where the exception is being caught. Meaning if nobody catches =
that exception the stack is unwound all the way, but that fails if there is=
 a catch(...) block anywhere that doesn't re-throw. I think it's a reasonab=
le requirement to say that nobody must have a catch(...) block that doesn't=
 re-throw if you want stack unwinding to work, but if the standard is to be=
 changed, then this could be made more robust. For example you could introd=
uce a magical exception type that automatically re-throws when caught, exce=
pt when it's caught by std::coroutine.<br><br>On Friday, March 15, 2013 1:4=
8:17 PM UTC-4, Oliver Kowalke wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">Hi,<br><br>this is the first version of the proposal to add coroutine=
s to C++.<br>The pdf can be found here: <a href=3D"http://ok73.funpic.de/co=
routine.pdf" target=3D"_blank">http://ok73.funpic.de/<wbr>coroutine.pdf</a>=
<br><br>so long,<br>Oliver<br><div></div></blockquote>

<p></p>

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

------=_Part_2_31464158.1363455808551--

.

------=_Part_346_31831572.1363458271180
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 16. M=E4rz 2013 18:43:28 UTC+1 schrieb maltes...@gmail.com:
>
> 1. You say that this is a library only change but you require that it has=
=20
> a stack that can grow on demand. As far as I know that can not currently =
be=20
> implemented in C++. So that would not make this a library only change,=20
> right? I think the requirement for growing stacks is a good one and we=20
> should not drop it just to make this a library only change. It might be a=
=20
> good idea to make the growing stack a separate class that is used by the=
=20
> coroutine.
>

On demand growing stacks can be used by C++ - I've already done it for=20
boost.coroutine (>=3D1.54 - currently in boost-trunk). But this requires=20
support by the compiler. As I wrote in the proposal I know only GCC (>=3D4.=
7)=20
to supports segmented/split stacks.
(OK - llvm has also segmented stack but the clang front end does not allow=
=20
to use it, at least not yet).
So, today we have already on demand growing stacks (you could try=20
boost.coroutine from boost-trunk -> 'b2 toolset=3Dgcc segmented-stack=3Don'=
). I=20
think the user should not deal with stack allocation etc. - this should be=
=20
done inside coroutine<>.
=20

> 2. Why does the coroutine get called from the constructor? You say that=
=20
> otherwise it is difficult to detect the completeness of a coroutine, but =
I=20
> don't understand why that would be. Can you explain the std::distance=20
> example you gave and why it wouldn't work if you created the coroutine in=
=20
> one line and called operator() in the next?
>

If we enter the coro-fn no at the coroutine<>-ctor you are forced to call=
=20
coroutine::operator() (which does the jump into coro-fn) 4-times. The 4th=
=20
time is required because after the 3thd jump from the coro-fn we still=20
don't know in the main-thread/task (caller don't now hat would be the best=
=20
wording) if the coro-fn would return another return value or would it be=20
terminate (=3D=3D return from coro-fn body).
In contrast to this - if we enter coro-fn with coroutine<>-ctor - we know=
=20
after the 3rd jump from coro-fn that the coro-.fn terminated.
=20

> 3. Why does operator() return the coroutine itself? I could understand if=
=20
> it returns the result (or a std::optional<result>) or void. But I don't s=
ee=20
> why it would return the coroutine itself. I think it should return void,=
=20
> because anything else is confusing. For example this will compile with=20
> boosts coroutine implementation:
>

in order to check if the coro-fn has returned a result or termianted

coroutine<bool ()> coro(/*...*/);
> bool result =3D coro(); // doesn't actually assign the result of the=20
> coroutine, but the current state instead
>

result would tell you if coro is still valid (=3D=3D coroutine<>::operator(=
)=20
can be called) or if coro-fn has teminated (=3D=3D you must nor call=20
coroutine<>::operator())
=20

> 4. How does the coroutine unwind the stack on destruction? I believe that=
=20
> in boost it's done by throwing an exception, which unwinds the stack from=
=20
> the point where you last left the coroutine to where the exception is bei=
ng=20
> caught.


yes - that is how boost.coroutine unwinds the stack (most generic one=20
because not all compiler implement __unwind API)
=20

> Meaning if nobody catches that exception the stack is unwound all the way=
,=20
> but that fails if there is a catch(...) block anywhere that doesn't=20
> re-throw.


no - boost.coroutine uses a trampoline function which catches the=20
unwind-exception
=20

> I think it's a reasonable requirement to say that nobody must have a=20
> catch(...) block that doesn't re-throw if you want stack unwinding to wor=
k,=20
> but if the standard is to be changed, then this could be made more robust=
..
>

I would expect that the compiler implementer calls its compiler specific=20
stack unwinding API so that throwing and catching a special=20
unwind-exception isn't necessary=20

--=20

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



------=_Part_346_31831572.1363458271180
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 16. M=E4rz 2013 18:43:28 UTC+1 schrieb maltes...@gmail.com:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">1. You say that this is a library =
only change but you require that it has a stack that can grow on demand. As=
 far as I know that can not currently be implemented in C++. So that would =
not make this a library only change, right? I think the requirement for gro=
wing stacks is a good one and we should not drop it just to make this a lib=
rary only change. It might be a good idea to make the growing stack a separ=
ate class that is used by the coroutine.<br></blockquote><div><br>On demand=
 growing stacks can be used by C++ - I've already done it for boost.corouti=
ne (&gt;=3D1.54 - currently in boost-trunk). But this requires support by t=
he compiler. As I wrote in the proposal I know only GCC (&gt;=3D4.7) to sup=
ports segmented/split stacks.<br>(OK - llvm has also segmented stack but th=
e clang front end does not allow to use it, at least not yet).<br>So, today=
 we have already on demand growing stacks (you could try boost.coroutine fr=
om boost-trunk -&gt; 'b2 toolset=3Dgcc segmented-stack=3Don'). I think the =
user should not deal with stack allocation etc. - this should be done insid=
e coroutine&lt;&gt;.<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">2. Why does the coroutine get called from the constructor? You say th=
at otherwise it is difficult to detect the completeness of a coroutine, but=
 I don't understand why that would be. Can you explain the std::distance ex=
ample you gave and why it wouldn't work if you created the coroutine in one=
 line and called operator() in the next?<br></blockquote><div><br>If we ent=
er the coro-fn no at the coroutine&lt;&gt;-ctor you are forced to call coro=
utine::operator() (which does the jump into coro-fn) 4-times. The 4th time =
is required because after the 3thd jump from the coro-fn we still don't kno=
w in the main-thread/task (caller don't now hat would be the best wording) =
if the coro-fn would return another return value or would it be terminate (=
=3D=3D return from coro-fn body).<br>In contrast to this - if we enter coro=
-fn with coroutine&lt;&gt;-ctor - we know after the 3rd jump from coro-fn t=
hat the coro-.fn terminated.<br>&nbsp;</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">3. Why does operator() return the coroutine itself? I could u=
nderstand if it returns the result (or a std::optional&lt;result&gt;) or vo=
id. But I don't see why it would return the coroutine itself. I think it sh=
ould return void, because anything else is confusing. For example this will=
 compile with boosts coroutine implementation:<br></blockquote><div><br>in =
order to check if the coro-fn has returned a result or termianted<br><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">coroutine&lt;bool ()&gt; c=
oro(/*...*/);<br>bool result =3D coro(); // doesn't actually assign the res=
ult of the coroutine, but the current state instead<br></blockquote><div><b=
r>result would tell you if coro is still valid (=3D=3D coroutine&lt;&gt;::o=
perator() can be called) or if coro-fn has teminated (=3D=3D you must nor c=
all coroutine&lt;&gt;::operator())<br>&nbsp;</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;">4. How does the coroutine unwind the stack on destructi=
on? I believe that in boost it's done by throwing an exception, which unwin=
ds the stack from the point where you last left the coroutine to where the =
exception is being caught.</blockquote><div><br>yes - that is how boost.cor=
outine unwinds the stack (most generic one because not all compiler impleme=
nt __unwind API)<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"> Meaning if nobody catches that exception the stack is unwound all the wa=
y, but that fails if there is a catch(...) block anywhere that doesn't re-t=
hrow.</blockquote><div><br>no - boost.coroutine uses a trampoline function =
which catches the unwind-exception<br>&nbsp;</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"> I think it's a reasonable requirement to say that nobo=
dy must have a catch(...) block that doesn't re-throw if you want stack unw=
inding to work, but if the standard is to be changed, then this could be ma=
de more robust.<br></blockquote><div><br>I would expect that the compiler i=
mplementer calls its compiler specific stack unwinding API so that throwing=
 and catching a special unwind-exception isn't necessary <br></div><div sty=
le=3D"display: none;" id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></d=
iv>

<p></p>

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

------=_Part_346_31831572.1363458271180--

.

------=_Part_1834_4200356.1363462295494
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, March 16, 2013 2:24:31 PM UTC-4, Oliver Kowalke wrote:
>
> Am Samstag, 16. M=E4rz 2013 18:43:28 UTC+1 schrieb maltes...@gmail.com:
>>
>> 1. You say that this is a library only change but you require that it ha=
s=20
>> a stack that can grow on demand. As far as I know that can not currently=
 be=20
>> implemented in C++. So that would not make this a library only change,=
=20
>> right? I think the requirement for growing stacks is a good one and we=
=20
>> should not drop it just to make this a library only change. It might be =
a=20
>> good idea to make the growing stack a separate class that is used by the=
=20
>> coroutine.
>>
>
> On demand growing stacks can be used by C++ - I've already done it for=20
> boost.coroutine (>=3D1.54 - currently in boost-trunk). But this requires=
=20
> support by the compiler. As I wrote in the proposal I know only GCC (>=3D=
4.7)=20
> to supports segmented/split stacks.
> (OK - llvm has also segmented stack but the clang front end does not allo=
w=20
> to use it, at least not yet).
> So, today we have already on demand growing stacks (you could try=20
> boost.coroutine from boost-trunk -> 'b2 toolset=3Dgcc segmented-stack=3Do=
n'). I=20
> think the user should not deal with stack allocation etc. - this should b=
e=20
> done inside coroutine<>.
>

If it requires support by the compiler then this is hardly a library only=
=20
change. I agree that the feature is needed, I just disagree with the=20
wording.

=20
>
>> 2. Why does the coroutine get called from the constructor? You say that=
=20
>> otherwise it is difficult to detect the completeness of a coroutine, but=
 I=20
>> don't understand why that would be. Can you explain the std::distance=20
>> example you gave and why it wouldn't work if you created the coroutine i=
n=20
>> one line and called operator() in the next?
>>
>
> If we enter the coro-fn no at the coroutine<>-ctor you are forced to call=
=20
> coroutine::operator() (which does the jump into coro-fn) 4-times. The 4th=
=20
> time is required because after the 3thd jump from the coro-fn we still=20
> don't know in the main-thread/task (caller don't now hat would be the bes=
t=20
> wording) if the coro-fn would return another return value or would it be=
=20
> terminate (=3D=3D return from coro-fn body).
> In contrast to this - if we enter coro-fn with coroutine<>-ctor - we know=
=20
> after the 3rd jump from coro-fn that the coro-.fn terminated.
>

Makes sense, but I still think that it's a bit strange. If this is only=20
needed for coroutine iterators, then maybe the initial call could be moved=
=20
into the non-member begin() function instead of the constructor.
I think that if a coroutine needs to be called four times, it should have=
=20
to be called four times. Not three times and once in the constructor.

I actually have another related question:
How do you tell the difference between the calling constructor and the=20
non-calling constructor for a coroutine<void()>? It looks like the current=
=20
boost implementation will always call the coroutine immediately if it's a=
=20
coroutine<void ()>. I would prefer that the default behavior is that the=20
coroutine does NOT get called immediately. That just makes it easier to use=
=20
the coroutine as a functor, for example as a callback to an observer=20
pattern.

=20
>
>> 3. Why does operator() return the coroutine itself? I could understand i=
f=20
>> it returns the result (or a std::optional<result>) or void. But I don't =
see=20
>> why it would return the coroutine itself. I think it should return void,=
=20
>> because anything else is confusing. For example this will compile with=
=20
>> boosts coroutine implementation:
>>
>
> in order to check if the coro-fn has returned a result or termianted
>
> coroutine<bool ()> coro(/*...*/);
>> bool result =3D coro(); // doesn't actually assign the result of the=20
>> coroutine, but the current state instead
>>
>
> result would tell you if coro is still valid (=3D=3D coroutine<>::operato=
r()=20
> can be called) or if coro-fn has teminated (=3D=3D you must nor call=20
> coroutine<>::operator())
>

But you could do the same thing by checking the coroutine itself instead of=
=20
checking the result of the operator(). I don't see what the benefit is. All=
=20
you get is essentially that you can write
while (some_coroutine()) {}
instead of
for (; some_coroutine; some_coroutine()) {}

I find it confusing if a functor doesn't return the result of it's call. I=
=20
understand why it shouldn't return the result, but I would prefer that it=
=20
return nothing instead.

As I understand it the reason for why it doesn't return the result is so=20
that there is only one way to return values from a coroutine, right? If=20
that is the case then I would prefer it if we require that the last=20
returned value from a coroutine has to be returned with a normal return=20
statement, like it was done in the old boost.coroutine. Then we could make=
=20
operator() return that value. And then a coroutine object is more useful as=
=20
a functor for algorithms like std::transform. Another benefit would be that=
=20
this would solve the problem you mentioned in response to my second=20
question, because a coroutine could not be called any more after it has=20
returned it's final value.

=20
>
>> 4. How does the coroutine unwind the stack on destruction? I believe tha=
t=20
>> in boost it's done by throwing an exception, which unwinds the stack fro=
m=20
>> the point where you last left the coroutine to where the exception is be=
ing=20
>> caught.
>
>
> yes - that is how boost.coroutine unwinds the stack (most generic one=20
> because not all compiler implement __unwind API)
> =20
>
>> Meaning if nobody catches that exception the stack is unwound all the=20
>> way, but that fails if there is a catch(...) block anywhere that doesn't=
=20
>> re-throw.
>
>
> no - boost.coroutine uses a trampoline function which catches the=20
> unwind-exception
> =20
>
>> I think it's a reasonable requirement to say that nobody must have a=20
>> catch(...) block that doesn't re-throw if you want stack unwinding to wo=
rk,=20
>> but if the standard is to be changed, then this could be made more robus=
t.
>>
>
> I would expect that the compiler implementer calls its compiler specific=
=20
> stack unwinding API so that throwing and catching a special=20
> unwind-exception isn't necessary=20
>

OK that's a good idea. But it is another change that requires compiler=20
support and can not be implemented as a library feature. It also makes it=
=20
so that you can only pass a noexcept function to a coroutine if you know=20
that it will complete before being destroyed. Which is not unreasonable,=20
but should be a written requirement.

--=20

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



------=_Part_1834_4200356.1363462295494
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Saturday, March 16, 2013 2:24:31 PM UTC-4, Oliver Kowalke wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">Am Samstag, 16. M=E4rz 2013 18:43:28 U=
TC+1 schrieb <a>maltes...@gmail.com</a>:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">1. You say that this is a library only change but you require that it =
has a stack that can grow on demand. As far as I know that can not currentl=
y be implemented in C++. So that would not make this a library only change,=
 right? I think the requirement for growing stacks is a good one and we sho=
uld not drop it just to make this a library only change. It might be a good=
 idea to make the growing stack a separate class that is used by the corout=
ine.<br></blockquote><div><br>On demand growing stacks can be used by C++ -=
 I've already done it for boost.coroutine (&gt;=3D1.54 - currently in boost=
-trunk). But this requires support by the compiler. As I wrote in the propo=
sal I know only GCC (&gt;=3D4.7) to supports segmented/split stacks.<br>(OK=
 - llvm has also segmented stack but the clang front end does not allow to =
use it, at least not yet).<br>So, today we have already on demand growing s=
tacks (you could try boost.coroutine from boost-trunk -&gt; 'b2 toolset=3Dg=
cc segmented-stack=3Don'). I think the user should not deal with stack allo=
cation etc. - this should be done inside coroutine&lt;&gt;.<br></div></bloc=
kquote><div><br>If it requires support by the compiler then this is hardly =
a library only change. I agree that the feature is needed, I just disagree =
with the wording.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">2. Why does the c=
oroutine get called from the constructor? You say that otherwise it is diff=
icult to detect the completeness of a coroutine, but I don't understand why=
 that would be. Can you explain the std::distance example you gave and why =
it wouldn't work if you created the coroutine in one line and called operat=
or() in the next?<br></blockquote><div><br>If we enter the coro-fn no at th=
e coroutine&lt;&gt;-ctor you are forced to call coroutine::operator() (whic=
h does the jump into coro-fn) 4-times. The 4th time is required because aft=
er the 3thd jump from the coro-fn we still don't know in the main-thread/ta=
sk (caller don't now hat would be the best wording) if the coro-fn would re=
turn another return value or would it be terminate (=3D=3D return from coro=
-fn body).<br>In contrast to this - if we enter coro-fn with coroutine&lt;&=
gt;-ctor - we know after the 3rd jump from coro-fn that the coro-.fn termin=
ated.<br></div></blockquote><div><br>Makes sense, but I still think that it=
's a bit strange. If this is only needed for coroutine iterators, then mayb=
e the initial call could be moved into the non-member begin() function inst=
ead of the constructor.<br>I think that if a coroutine needs to be called f=
our times, it should have to be called four times. Not three times and once=
 in the constructor.<br><br>I actually have another related question:<br>Ho=
w do you tell the difference between the calling constructor and the non-ca=
lling constructor for a coroutine&lt;void()&gt;? It looks like the current =
boost implementation will always call the coroutine immediately if it's a c=
oroutine&lt;void ()&gt;. I would prefer that the default behavior is that t=
he coroutine does NOT get called immediately. That just makes it easier to =
use the coroutine as a functor, for example as a callback to an observer pa=
ttern.<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>&nbsp=
;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">3. Why does operator() retur=
n the coroutine itself? I could understand if it returns the result (or a s=
td::optional&lt;result&gt;) or void. But I don't see why it would return th=
e coroutine itself. I think it should return void, because anything else is=
 confusing. For example this will compile with boosts coroutine implementat=
ion:<br></blockquote><div><br>in order to check if the coro-fn has returned=
 a result or termianted<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex=
">coroutine&lt;bool ()&gt; coro(/*...*/);<br>bool result =3D coro(); // doe=
sn't actually assign the result of the coroutine, but the current state ins=
tead<br></blockquote><div><br>result would tell you if coro is still valid =
(=3D=3D coroutine&lt;&gt;::operator() can be called) or if coro-fn has temi=
nated (=3D=3D you must nor call coroutine&lt;&gt;::operator())<br></div></b=
lockquote><div><br>But you could do the same thing by checking the coroutin=
e itself instead of checking the result of the operator(). I don't see what=
 the benefit is. All you get is essentially that you can write<br>while (so=
me_coroutine()) {}<br>instead of<br>for (; some_coroutine; some_coroutine()=
) {}<br><br>I find it confusing if a functor doesn't return the result of i=
t's call. I understand why it shouldn't return the result, but I would pref=
er that it return nothing instead.<br><br>As I understand it the reason for=
 why it doesn't return the result is so that there is only one way to retur=
n values from a coroutine, right? If that is the case then I would prefer i=
t if we require that the last returned value from a coroutine has to be ret=
urned with a normal return statement, like it was done in the old boost.cor=
outine. Then we could make operator() return that value. And then a corouti=
ne object is more useful as a functor for algorithms like std::transform. A=
nother benefit would be that this would solve the problem you mentioned in =
response to my second question, because a coroutine could not be called any=
 more after it has returned it's final value.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">4. How does the coroutine unwind the stack on destruction? I bel=
ieve that in boost it's done by throwing an exception, which unwinds the st=
ack from the point where you last left the coroutine to where the exception=
 is being caught.</blockquote><div><br>yes - that is how boost.coroutine un=
winds the stack (most generic one because not all compiler implement __unwi=
nd API)<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> Meaning if =
nobody catches that exception the stack is unwound all the way, but that fa=
ils if there is a catch(...) block anywhere that doesn't re-throw.</blockqu=
ote><div><br>no - boost.coroutine uses a trampoline function which catches =
the unwind-exception<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
> I think it's a reasonable requirement to say that nobody must have a catc=
h(...) block that doesn't re-throw if you want stack unwinding to work, but=
 if the standard is to be changed, then this could be made more robust.<br>=
</blockquote><div><br>I would expect that the compiler implementer calls it=
s compiler specific stack unwinding API so that throwing and catching a spe=
cial unwind-exception isn't necessary <br></div></blockquote><div><br>OK th=
at's a good idea. But it is another change that requires compiler support a=
nd can not be implemented as a library feature. It also makes it so that yo=
u can only pass a noexcept function to a coroutine if you know that it will=
 complete before being destroyed. Which is not unreasonable, but should be =
a written requirement.<br></div>

<p></p>

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

------=_Part_1834_4200356.1363462295494--

.

------=_Part_334_9917570.1363471921746
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 16. M=E4rz 2013 20:31:35 UTC+1 schrieb maltes...@gmail.com:
>
> If it requires support by the compiler then this is hardly a library only=
=20
> change. I agree that the feature is needed, I just disagree with the=20
> wording.
>

I wrote that it does not change the current C++ standard - not that=20
segmented stacks  can be implemented by a library only
=20

> Makes sense, but I still think that it's a bit strange. If this is only=
=20
> needed for coroutine iterators, then maybe the initial call could be move=
d=20
> into the non-member begin() function instead of the constructor.
>

no it is not only required by iterators - it influences how the state of a=
=20
coroutine can be checked hand how returned results can be accessed
for instance ctor of std::thread enters the thread-fn too
=20

> I think that if a coroutine needs to be called four times, it should have=
=20
> to be called four times. Not three times and once in the constructor.
>

this not an argument - you pass 3 return values back, so you would expect=
=20
to call coroutine 3 times
=20

> How do you tell the difference between the calling constructor and the=20
> non-calling constructor for a coroutine<void()>?=20
>

I don't get it what you mean - there is no non-calling ctor nor is=20
coroutine<void()> special or differrent to other coroutine<> instances
=20

> It looks like the current boost implementation will always call the=20
> coroutine immediately if it's a coroutine<void ()>.
>

yes, and for other coroutines the ctor calls the coro-fn too
=20

> I would prefer that the default behavior is that the coroutine does NOT=
=20
> get called immediately.
>

no - as I explained it would make using and implementing a coroutine harder
=20

> That just makes it easier to use the coroutine as a functor, for example=
=20
> as a callback to an observer pattern.
>

a coroutine is not a functor - we have had the same discussion for this=20
during the review process of boost.coroutine
I've had a version which did not call coro-fn in the ctor and we came up=20
with some examples where this design was not so good
=20

> But you could do the same thing by checking the coroutine itself instead=
=20
> of checking the result of the operator(). I don't see what the benefit is=
..=20
> All you get is essentially that you can write
> while (some_coroutine()) {}
> instead of
> for (; some_coroutine; some_coroutine()) {}
>

with the current design you could also do while(coro())

because the proposed interface contains following member functions:

coroutine & operator()()
operator bool()

because operator() does the jump and returns a reference to the coroutine=
=20
self the operator bool() is called in the while loop

I find it confusing if a functor doesn't return the result of it's call. I=
=20
> understand why it shouldn't return the result, but I would prefer that it=
=20
> return nothing instead.
>

you must not compare a coroutine to a function/functor it is different

with the current design you store the resultof the last jump inside the=20
coroutine and you can access it multiple times and you know after returning=
=20
from the context jump if the call returned a value

while (coro())
 coro.get();

coro().get()

we have discussed this design during the review too and the boost=20
developers in the review voted to store the result inside the coroutine and=
=20
access it via coroutine<>::get()

you must always check the coroutine before you try to access the returned=
=20
value
=20

> As I understand it the reason for why it doesn't return the result is so=
=20
> that there is only one way to return values from a coroutine, right?
>

it should anly one way how a coroutine can pass values back
=20

> If that is the case then I would prefer it if we require that the last=20
> returned value from a coroutine has to be returned with a normal return=
=20
> statement, like it was done in the old boost.coroutine.
>

in some cases the coro-fn would become a wired structure - for instance for=
=20
returning values from loops - then the last result must be returned by a=20
return statement.
the example below becomes more natureal with the current design

void fibonacci( boost::coroutines::coroutine< void( int) > & c)
{
    int first =3D 1, second =3D 1;
    for ( int i =3D 0; i < 10; ++i)
    {
        int third =3D first + second;
        first =3D second;
        second =3D third;
        c( third);    =20
    }
   // if coro-fn would not return void then the last value must be returned=
=20
here, outside the loop
}

boost::coroutines::coroutine< int() > c( fibonacci);
while( c) {
  std::cout << c.get() << std::endl;
}

=20
>
> Then we could make operator() return that value.
>

this does not depend on if the last value was returned by a 'return'=20
statement or by coroutine<>::operator()(...)
=20

> And then a coroutine object is more useful as a functor for algorithms=20
> like std::transform.=20
>

a coroutine is not a functor and it can be used with algorithms form the=20
stl (see examples in the proposal)

=20

> It also makes it so that you can only pass a noexcept function to a=20
> coroutine if you know that it will complete before being destroyed. Which=
=20
> is not unreasonable, but should be a written requirement.
>

I don't get it - you can pass a none-noexcept function to a coroutine too.=
=20
The exception thrown inside coro-fn is catched and stored inside the=20
coroutine and rethrown from operator() after return to the calling context=
=20

--=20

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



------=_Part_334_9917570.1363471921746
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 16. M=E4rz 2013 20:31:35 UTC+1 schrieb maltes...@gmail.com:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div>If it requires support by the=
 compiler then this is hardly a library only change. I agree that the featu=
re is needed, I just disagree with the wording.<br></div></blockquote><div>=
<br>I wrote that it does not change the current C++ standard - not that seg=
mented stacks&nbsp; can be implemented by a library only<br>&nbsp;</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div>Makes sense, but I still thi=
nk that it's a bit strange. If this is only needed for coroutine iterators,=
 then maybe the initial call could be moved into the non-member begin() fun=
ction instead of the constructor.<br></div></blockquote><div><br>no it is n=
ot only required by iterators - it influences how the state of a coroutine =
can be checked hand how returned results can be accessed<br>for instance ct=
or of std::thread enters the thread-fn too<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>I think that if a coroutine needs to be ca=
lled four times, it should have to be called four times. Not three times an=
d once in the constructor.<br></div></blockquote><div><br>this not an argum=
ent - you pass 3 return values back, so you would expect to call coroutine =
3 times<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Ho=
w do you tell the difference between the calling constructor and the non-ca=
lling constructor for a coroutine&lt;void()&gt;? </div></blockquote><div><b=
r>I don't get it what you mean - there is no non-calling ctor nor is corout=
ine&lt;void()&gt; special or differrent to other coroutine&lt;&gt; instance=
s<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>It looks=
 like the current boost implementation will always call the coroutine immed=
iately if it's a coroutine&lt;void ()&gt;.</div></blockquote><div><br>yes, =
and for other coroutines the ctor calls the coro-fn too<br>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div> I would prefer that the defa=
ult behavior is that the coroutine does NOT get called immediately.</div></=
blockquote><div><br>no - as I explained it would make using and implementin=
g a coroutine harder<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div>That just makes it easier to use the coroutine as a functor, for=
 example as a callback to an observer pattern.<br></div></blockquote><div><=
br>a coroutine is not a functor - we have had the same discussion for this =
during the review process of boost.coroutine<br>I've had a version which di=
d not call coro-fn in the ctor and we came up with some examples where this=
 design was not so good<br>&nbsp;</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div>But you could do the same thing by checking the coroutine its=
elf instead of checking the result of the operator(). I don't see what the =
benefit is. All you get is essentially that you can write<br>while (some_co=
routine()) {}<br>instead of<br>for (; some_coroutine; some_coroutine()) {}<=
br></div></blockquote><div><br>with the current design you could also do wh=
ile(coro())<br><br>because the proposed interface contains following member=
 functions:<br><br>coroutine &amp; operator()()<br>operator bool()<br><br>b=
ecause operator() does the jump and returns a reference to the coroutine se=
lf the operator bool() is called in the while loop<br><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div>I find it confusing if a functor doe=
sn't return the result of it's call. I understand why it shouldn't return t=
he result, but I would prefer that it return nothing instead.<br></div></bl=
ockquote><div><br>you must not compare a coroutine to a function/functor it=
 is different<br><br>with the current design you store the resultof the las=
t jump inside the coroutine and you can access it multiple times and you kn=
ow after returning from the context jump if the call returned a value<br><b=
r>while (coro())<br>&nbsp;coro.get();<br><br>coro().get()<br><br>we have di=
scussed this design during the review too and the boost developers in the r=
eview voted to store the result inside the coroutine and access it via coro=
utine&lt;&gt;::get()<br><br>you must always check the coroutine before you =
try to access the returned value<br>&nbsp;</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div>As I understand it the reason for why it doesn't ret=
urn the result is so that there is only one way to return values from a cor=
outine, right?</div></blockquote><div><br>it should anly one way how a coro=
utine can pass values back<br>&nbsp;</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div>If that is the case then I would prefer it if we require t=
hat the last returned value from a coroutine has to be returned with a norm=
al return statement, like it was done in the old boost.coroutine.</div></bl=
ockquote><br>in some cases the coro-fn would become a wired structure - for=
 instance for returning values from loops - then the last result must be re=
turned by a return statement.<br>the example below becomes more natureal wi=
th the current design<br><br>void fibonacci( boost::coroutines::coroutine&l=
t; void( int) &gt; &amp; c)<br>{<br>&nbsp;&nbsp;&nbsp; int first =3D 1, sec=
ond =3D 1;<br>&nbsp;&nbsp;&nbsp; for ( int i =3D 0; i &lt; 10; ++i)<br>&nbs=
p;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int third =
=3D first + second;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; first =3D=
 second;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; second =3D third;<br=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c( third);&nbsp;&nbsp;&nbsp;&nb=
sp; <br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp; // if coro-fn would not return=
 void then the last value must be returned here, outside the loop<br>}<br><=
br>boost::coroutines::coroutine&lt; int() &gt; c( fibonacci);<br>while( c) =
{<br>&nbsp; std::cout &lt;&lt; c.get() &lt;&lt; std::endl;<br>}<br><br>&nbs=
p;<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div> Then we could make ope=
rator() return that value.</div></blockquote><div><br>this does not depend =
on if the last value was returned by a 'return' statement or by coroutine&l=
t;&gt;::operator()(...)<br>&nbsp;</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div>And then a coroutine object is more useful as a functor for a=
lgorithms like std::transform. </div></blockquote><div><br>a coroutine is n=
ot a functor and it can be used with algorithms form the stl (see examples =
in the proposal)</div><div><br>&nbsp;</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"></blockquote><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
>It also makes it so that you can only pass a noexcept function to a corout=
ine if you know that it will complete before being destroyed. Which is not =
unreasonable, but should be a written requirement.<br></div></blockquote><d=
iv><br>I don't get it - you can pass a none-noexcept function to a coroutin=
e too. The exception thrown inside coro-fn is catched and stored inside the=
 coroutine and rethrown from operator() after return to the calling context=
 <br></div><div style=3D"display: none;" id=3D"__af745f8f43-e961-4b88-8424-=
80b67790c964__"></div>

<p></p>

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

------=_Part_334_9917570.1363471921746--

.

------=_Part_406_1647897.1363500031663
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 16. M=E4rz 2013 23:12:01 UTC+1 schrieb Oliver Kowalke:
>
> Am Samstag, 16. M=E4rz 2013 20:31:35 UTC+1 schrieb maltes...@gmail.co
> =20
>
>> If that is the case then I would prefer it if we require that the last=
=20
>> returned value from a coroutine has to be returned with a normal return=
=20
>> statement, like it was done in the old boost.coroutine.
>>
>
> in some cases the coro-fn would become a wired structure - for instance=
=20
> for returning values from loops - then the last result must be returned b=
y=20
> a return statement.
>

you could also take a look at the visitor example contained in the proposal=
=20
(and in boost.coroutine too) - returning the last leaf node via a=20
'return'-statement is very hard (or nearly impossible -> how do you know in=
=20
the recursive traversion of the tree that you reached the last leaf node?)

--=20

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



------=_Part_406_1647897.1363500031663
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 16. M=E4rz 2013 23:12:01 UTC+1 schrieb Oliver Kowalke:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">Am Samstag, 16. M=E4rz 2013 20:31:35 UT=
C+1 schrieb <a>maltes...@gmail.co</a><br><div>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div>If that is the case then I would prefer it if w=
e require that the last returned value from a coroutine has to be returned =
with a normal return statement, like it was done in the old boost.coroutine=
..</div></blockquote><br>in some cases the coro-fn would become a wired stru=
cture - for instance for returning values from loops - then the last result=
 must be returned by a return statement.<br></blockquote><div><br>you could=
 also take a look at the visitor example contained in the proposal (and in =
boost.coroutine too) - returning the last leaf node via a 'return'-statemen=
t is very hard (or nearly impossible -&gt; how do you know in the recursive=
 traversion of the tree that you reached the last leaf node?)<br></div><div=
 style=3D"display: none;" id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"=
></div>

<p></p>

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

------=_Part_406_1647897.1363500031663--

.

--bcaec5430a10a768cd04d8199f04
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK those are good reasons to allow returning without a value. You've got me
convinced.
Could you also post a link to the discussions on the boost mailing list? I
don't want to ask questions that have already been discussed.

Has there been any thought to yielding without a value? It might be useful
if the coroutine is computing something that takes a while but it wants to
give up control of the thread every now and then. All that would be
required is that the coroutine has a operator() that takes no arguments. A
coroutine can already be in a state where it doesn't have a result from the
call, so this wouldn't complicate things all that much.
I also think that this is needed because there is this weird asymmetry with
the first call from the constructor where the function inside of the
coroutine may be called without arguments. But it has to return a value
anyway. I think it would make sense if the inner function can say "If I
don't have any arguments yet, yield without a return value until I get
arguments."

As for the noexcept thing: What I meant is that if your function is
noexcept, you have to be certain that the coroutine will finish, because
stack unwinding will terminate the program. You can try that with the stack
unwinding example from the boost website: If you make the function in there
be noexcept the program will call terminate().

2013/3/17 Oliver Kowalke <oliver.kowalke@gmail.com>

> Am Samstag, 16. M=E4rz 2013 23:12:01 UTC+1 schrieb Oliver Kowalke:
>>
>> Am Samstag, 16. M=E4rz 2013 20:31:35 UTC+1 schrieb maltes...@gmail.co
>>
>>
>>> If that is the case then I would prefer it if we require that the last
>>> returned value from a coroutine has to be returned with a normal return
>>> statement, like it was done in the old boost.coroutine.
>>>
>>
>> in some cases the coro-fn would become a wired structure - for instance
>> for returning values from loops - then the last result must be returned =
by
>> a return statement.
>>
>
> you could also take a look at the visitor example contained in the
> proposal (and in boost.coroutine too) - returning the last leaf node via =
a
> 'return'-statement is very hard (or nearly impossible -> how do you know =
in
> the recursive traversion of the tree that you reached the last leaf node?=
)
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3g6ZIWedGJ8/=
unsubscribe?hl=3Den
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.
>
>
>

--=20

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



--bcaec5430a10a768cd04d8199f04
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK those are good reasons to allow returning without a value. You&#39;ve go=
t me convinced.<br>Could you also post a link to the discussions on the boo=
st mailing list? I don&#39;t want to ask questions that have already been d=
iscussed.<br>

<br>Has there been any thought to yielding without a value? It might be use=
ful if the coroutine is computing something that takes a while but it wants=
 to give up control of the thread every now and then. All that would be req=
uired is that the coroutine has a operator() that takes no arguments. A cor=
outine can already be in a state where it doesn&#39;t have a result from th=
e call, so this wouldn&#39;t complicate things all that much.<br>

I also think that this is needed because there is this weird asymmetry with=
 the first call from the constructor where the function inside of the corou=
tine may be called without arguments. But it has to return a value anyway. =
I think it would make sense if the inner function can say &quot;If I don&#3=
9;t have any arguments yet, yield without a return value until I get argume=
nts.&quot;<br>

<br>As for the noexcept thing: What I meant is that if your function is noe=
xcept, you have to be certain that the coroutine will finish, because stack=
 unwinding will terminate the program. You can try that with the stack unwi=
nding example from the boost website: If you make the function in there be =
noexcept the program will call terminate().<br>

<br><div class=3D"gmail_quote">2013/3/17 Oliver Kowalke <span dir=3D"ltr">&=
lt;<a href=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">oliver.kow=
alke@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">

Am Samstag, 16. M=E4rz 2013 23:12:01 UTC+1 schrieb Oliver Kowalke:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">Am Samstag, 16. M=E4rz 201=
3 20:31:35 UTC+1 schrieb <a>maltes...@gmail.co</a><br>

<div>=A0</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>If that is=
 the case then I would prefer it if we require that the last returned value=
 from a coroutine has to be returned with a normal return statement, like i=
t was done in the old boost.coroutine.</div>

</blockquote><div class=3D"im"><br>in some cases the coro-fn would become a=
 wired structure - for instance for returning values from loops - then the =
last result must be returned by a return statement.<br></div></blockquote>

<div><br>you could also take a look at the visitor example contained in the=
 proposal (and in boost.coroutine too) - returning the last leaf node via a=
 &#39;return&#39;-statement is very hard (or nearly impossible -&gt; how do=
 you know in the recursive traversion of the tree that you reached the last=
 leaf node?)<br>

</div><div class=3D"HOEnZb"><div class=3D"h5"><div></div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/3g6ZIWedGJ8/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3g=
6ZIWedGJ8/unsubscribe?hl=3Den</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br>

<p></p>

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

--bcaec5430a10a768cd04d8199f04--

.

------=_Part_161_13886655.1363506705006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Sonntag, 17. M=E4rz 2013 08:14:11 UTC+1 schrieb Malte Skarupke:

> Could you also post a link to the discussions on the boost mailing list? =
I=20
> don't want to ask questions that have already been discussed.
>

some threadds can be found here:=20
http://search.gmane.org/search.php?group=3Dgmane.comp.lib.boost.devel&query=
=3Dboost.coroutine+review
=20

> Has there been any thought to yielding without a value? It might be usefu=
l=20
> if the coroutine is computing something that takes a while but it wants t=
o=20
> give up control of the thread every now and then. All that would be=20
> required is that the coroutine has a operator() that takes no arguments. =
A=20
> coroutine can already be in a state where it doesn't have a result from t=
he=20
> call, so this wouldn't complicate things all that much.
>

I think this does not belong to coroutine - with the template argument of=
=20
coroutine you say that the coroutine is expected to return a value of a=20
certain kind of type given in the template signature.
I think what you propose belong to a fiber (you can take a look at=20
gitbub.com/olk/boost-fiber)
=20

> I also think that this is needed because there is this weird asymmetry=20
> with the first call from the constructor where the function inside of the=
=20
> coroutine may be called without arguments. But it has to return a value=
=20
> anyway.
>

you can call coroutine's ctor with or without arguments - depends on the=20
code in your coro-fn
=20

> As for the noexcept thing: What I meant is that if your function is=20
> noexcept, you have to be certain that the coroutine will finish, because=
=20
> stack unwinding will terminate the program. You can try that with the sta=
ck=20
> unwinding example from the boost website: If you make the function in the=
re=20
> be noexcept the program will call terminate().
>

OK - I got it. Of course the current solution is a vehicle. I tried some=20
APIs for stack unwinding (destructing objects allocated on the stack) - but=
=20
the most generic solution was to throw an exception.
It is a limitation of boost.coroutine - the compiler vendors can easily=20
unwind the stack using their internal API for destructing objects (if they=
=20
go out of scope).

--=20

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



------=_Part_161_13886655.1363506705006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Sonntag, 17. M=E4rz 2013 08:14:11 UTC+1 schrieb Malte Skarupke:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">Could you also post a link to the d=
iscussions on the boost mailing list? I don't want to ask questions that ha=
ve already been discussed.<br></blockquote><div><br>some threadds can be fo=
und here: http://search.gmane.org/search.php?group=3Dgmane.comp.lib.boost.d=
evel&amp;query=3Dboost.coroutine+review<br>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">

Has there been any thought to yielding without a value? It might be useful =
if the coroutine is computing something that takes a while but it wants to =
give up control of the thread every now and then. All that would be require=
d is that the coroutine has a operator() that takes no arguments. A corouti=
ne can already be in a state where it doesn't have a result from the call, =
so this wouldn't complicate things all that much.<br></blockquote><div><br>=
I think this does not belong to coroutine - with the template argument=20
of coroutine you say that the coroutine is expected to return a value of
 a certain kind of type given in the template signature.<br>I think what yo=
u propose belong to a fiber (you can take a look at gitbub.com/olk/boost-fi=
ber)<br>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">

I also think that this is needed because there is this weird asymmetry with=
 the first call from the constructor where the function inside of the corou=
tine may be called without arguments. But it has to return a value anyway.<=
br></blockquote><div><br>you can call coroutine's ctor with or without argu=
ments - depends on the code in your coro-fn<br>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">

As for the noexcept thing: What I meant is that if your function is noexcep=
t, you have to be certain that the coroutine will finish, because stack unw=
inding will terminate the program. You can try that with the stack unwindin=
g example from the boost website: If you make the function in there be noex=
cept the program will call terminate().<br></blockquote><div><br>OK - I got=
 it. Of course the current solution is a vehicle. I tried some APIs for sta=
ck unwinding (destructing objects allocated on the stack) - but the most ge=
neric solution was to throw an exception.<br>It is a limitation of boost.co=
routine - the compiler vendors can easily unwind the stack using their inte=
rnal API for destructing objects (if they go out of scope).<br></div><div s=
tyle=3D"display: none;" id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"><=
/div>

<p></p>

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

------=_Part_161_13886655.1363506705006--

.

* Oliver Kowalke:

> On demand growing stacks can be used by C++ - I've already done it
> for boost.coroutine (>=1.54 - currently in boost-trunk). But this
> requires support by the compiler. As I wrote in the proposal I know
> only GCC (>=4.7) to supports segmented/split stacks.

Only on some architectures, and all system libraries are typically
compiled without support for split stacks.  (Stack growth is still on
demand, of course, but happens in page size increments, and address
space for the maximum stack size is reserved beforehand, sometimes
causing problems on 32 bit architectures).

It is also difficult to phrase this requirement in a meaningful way.
This is quite similar to operator delete, which is not guaranteed to
free storage.  (Actually, for each common implementation, there is a
sequence of operator new/delete calls which behaves as if some
operator delete calls never free storage for later re-use, because of
fragmentation.)

--

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



.

* Oliver Kowalke:

> this is the first version of the proposal to add coroutines to C++.
> The pdf can be found here: http://ok73.funpic.de/coroutine.pdf

What's the interaction with thread_local?

--

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



.

------=_Part_438_28931402.1363555474837
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Am Sonntag, 17. M=E4rz 2013 20:18:56 UTC+1 schrieb Florian Weimer:
>
> * Oliver Kowalke:=20
>
> > this is the first version of the proposal to add coroutines to C++.=20
> > The pdf can be found here: http://ok73.funpic.de/coroutine.pdf=20
>
> What's the interaction with thread_local?
>

the proposal tells nothing about threads - thread are out out of scope


--=20

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



------=_Part_438_28931402.1363555474837
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Sonntag, 17. M=E4rz 2013 20:18:56 UTC+1 schrieb Florian Weimer:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">* Oliver Kowalke:
<br>
<br>&gt; this is the first version of the proposal to add coroutines to C++=
..
<br>&gt; The pdf can be found here: <a href=3D"http://ok73.funpic.de/corout=
ine.pdf" target=3D"_blank">http://ok73.funpic.de/<wbr>coroutine.pdf</a>
<br>
<br>What's the interaction with thread_local?<br></blockquote><div><br>the =
proposal tells nothing about threads - thread are out out of scope<br><br><=
br></div><div style=3D"display: none;" id=3D"__af745f8f43-e961-4b88-8424-80=
b67790c964__"></div>

<p></p>

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

------=_Part_438_28931402.1363555474837--

.

* Oliver Kowalke:

> Am Sonntag, 17. M=E4rz 2013 20:18:56 UTC+1 schrieb Florian Weimer:
>>
>> * Oliver Kowalke:=20
>>
>> > this is the first version of the proposal to add coroutines to C++.=20
>> > The pdf can be found here: http://ok73.funpic.de/coroutine.pdf=20
>>
>> What's the interaction with thread_local?
>>
>
> the proposal tells nothing about threads - thread are out out of scope

I don't think you've got a choice in this matter.

You still have to specify what coroutine resume/yield does to
thread_local variables.  Coroutine-specific variables are difficult to
implement on some platforms.  If coroutines just use the thread_local
variables of the executing thread, some currently valid compiler
optimizations are broken.  For example, with coroutines, the address
of a thread_local variable can change during a function call, which is
currently impossible.

One way out of this is to specify that a coroutine must not be resumed
on a different thread.  But this is awfully restrictive.

--=20

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



.

------=_Part_671_9468242.1363591546486
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Montag, 18. M=E4rz 2013 00:55:25 UTC+1 schrieb Florian Weimer:
>
> > the proposal tells nothing about threads - thread are out out of scope=
=20
>
> I don't think you've got a choice in this matter.=20
>
> You still have to specify what coroutine resume/yield does to=20
> thread_local variables.  Coroutine-specific variables are difficult to=20
> implement on some platforms.  If coroutines just use the thread_local=20
> variables of the executing thread, some currently valid compiler=20
> optimizations are broken.  For example, with coroutines, the address=20
> of a thread_local variable can change during a function call, which is=20
> currently impossible.=20
>
> One way out of this is to specify that a coroutine must not be resumed=20
> on a different thread.  But this is awfully restrictive.
>


coroutines usually are a kind of extended function call - a coroutine=20
preserves and restores
instruction pointer, stack pointer and some CPU registers  defined by the=
=20
ABI.
If you execute coroutines using thread-local storage then the code should=
=20
work
as usual code (without coroutines).
If you migrate coroutines using thread-local storage between threads then=
=20
the same restrictions
as for usual code should apply.

sorry - I still don't get your concerns.

--=20

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



------=_Part_671_9468242.1363591546486
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Montag, 18. M=E4rz 2013 00:55:25 UTC+1 schrieb Florian Weimer:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">&gt; the proposal tells nothing about th=
reads - thread are out out of scope
<br>
<br>I don't think you've got a choice in this matter.
<br>
<br>You still have to specify what coroutine resume/yield does to
<br>thread_local variables. &nbsp;Coroutine-specific variables are difficul=
t to
<br>implement on some platforms. &nbsp;If coroutines just use the thread_lo=
cal
<br>variables of the executing thread, some currently valid compiler
<br>optimizations are broken. &nbsp;For example, with coroutines, the addre=
ss
<br>of a thread_local variable can change during a function call, which is
<br>currently impossible.
<br>
<br>One way out of this is to specify that a coroutine must not be resumed
<br>on a different thread. &nbsp;But this is awfully restrictive.<br></bloc=
kquote><div><br><br>coroutines usually are a kind of extended function call=
 - a coroutine preserves and restores<br>instruction pointer, stack pointer=
 and some CPU registers&nbsp; defined by the ABI.<br>If you execute corouti=
nes using thread-local storage then the code should work<br>as usual code (=
without coroutines).<br>If you migrate coroutines using thread-local storag=
e between threads then the same restrictions<br>as for usual code should ap=
ply.<br><br>sorry - I still don't get your concerns.<br></div>

<p></p>

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

------=_Part_671_9468242.1363591546486--

.

------=_Part_1242_15868618.1363605583220
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Monday, March 18, 2013 7:25:46 AM UTC, Oliver Kowalke wrote:
>
> Am Montag, 18. M=E4rz 2013 00:55:25 UTC+1 schrieb Florian Weimer:
>>
>> > the proposal tells nothing about threads - thread are out out of scope=
=20
>>
>> I don't think you've got a choice in this matter.=20
>>
>> You still have to specify what coroutine resume/yield does to=20
>> thread_local variables.  Coroutine-specific variables are difficult to=
=20
>> implement on some platforms.  If coroutines just use the thread_local=20
>> variables of the executing thread, some currently valid compiler=20
>> optimizations are broken.  For example, with coroutines, the address=20
>> of a thread_local variable can change during a function call, which is=
=20
>> currently impossible.=20
>>
>> One way out of this is to specify that a coroutine must not be resumed=
=20
>> on a different thread.  But this is awfully restrictive.
>>
>
>
> coroutines usually are a kind of extended function call - a coroutine=20
> preserves and restores
> instruction pointer, stack pointer and some CPU registers  defined by the=
=20
> ABI.
> If you execute coroutines using thread-local storage then the code should=
=20
> work
> as usual code (without coroutines).
> If you migrate coroutines using thread-local storage between threads then=
=20
> the same restrictions
> as for usual code should apply.
>
> sorry - I still don't get your concerns.
>

Some ABIs use a thread status register that it is used to refer to thread=
=20
local storage. Compilers do assume that the value of this register is=20
preserved across function calls and optimize accordingly (for example=20
hoisting thread local storage address computations). If a coroutine is=20
moved from one thread to another, the assumption obviously does not hold.=
=20
In fact it would be wrong for a coroutine to preserve the thread status=20
register. This means that coroutines put a constraint on compiler=20
optimizations. This constraint should be mentioned.=20

-- gpd

=20

--=20

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



------=_Part_1242_15868618.1363605583220
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Monday, March 18, 2013 7:25:46 AM UTC, Oliver Kowalke wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">Am Montag, 18. M=E4rz 2013 00:55:25 UT=
C+1 schrieb Florian Weimer:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; the=
 proposal tells nothing about threads - thread are out out of scope
<br>
<br>I don't think you've got a choice in this matter.
<br>
<br>You still have to specify what coroutine resume/yield does to
<br>thread_local variables. &nbsp;Coroutine-specific variables are difficul=
t to
<br>implement on some platforms. &nbsp;If coroutines just use the thread_lo=
cal
<br>variables of the executing thread, some currently valid compiler
<br>optimizations are broken. &nbsp;For example, with coroutines, the addre=
ss
<br>of a thread_local variable can change during a function call, which is
<br>currently impossible.
<br>
<br>One way out of this is to specify that a coroutine must not be resumed
<br>on a different thread. &nbsp;But this is awfully restrictive.<br></bloc=
kquote><div><br><br>coroutines usually are a kind of extended function call=
 - a coroutine preserves and restores<br>instruction pointer, stack pointer=
 and some CPU registers&nbsp; defined by the ABI.<br>If you execute corouti=
nes using thread-local storage then the code should work<br>as usual code (=
without coroutines).<br>If you migrate coroutines using thread-local storag=
e between threads then the same restrictions<br>as for usual code should ap=
ply.<br><br>sorry - I still don't get your concerns.<br></div></blockquote>=
<div><br>Some ABIs use a thread status register that it is used to refer to=
 thread local storage. Compilers do assume that the value of this register =
is preserved across function calls and optimize accordingly (for example ho=
isting thread local storage address computations). If a coroutine is moved =
from one thread to another, the assumption obviously does not hold. In fact=
 it would be wrong for a coroutine to preserve the thread status register. =
This means that coroutines put a constraint on compiler optimizations. This=
 constraint should be mentioned. <br><br>-- gpd<br><br>&nbsp;</div>

<p></p>

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

------=_Part_1242_15868618.1363605583220--

.

------=_Part_1185_27481530.1363608609056
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Montag, 18. M=E4rz 2013 12:19:43 UTC+1 schrieb Giovanni Piero Deretta:
>
> Some ABIs use a thread status register that it is used to refer to thread=
=20
> local storage. Compilers do assume that the value of this register is=20
> preserved across function calls and optimize accordingly (for example=20
> hoisting thread local storage address computations). If a coroutine is=20
> moved from one thread to another, the assumption obviously does not hold.=
=20
> In fact it would be wrong for a coroutine to preserve the thread status=
=20
> register. This means that coroutines put a constraint on compiler=20
> optimizations. This constraint should be mentioned.=20
>

But this constraint is not special to coroutines it applies to ordinary=20
code too?!

--=20

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



------=_Part_1185_27481530.1363608609056
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Montag, 18. M=E4rz 2013 12:19:43 UTC+1 schrieb Giovanni Piero Deretta:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div>Some ABIs use a thread stat=
us register that it is used to refer to thread local storage. Compilers do =
assume that the value of this register is preserved across function calls a=
nd optimize accordingly (for example hoisting thread local storage address =
computations). If a coroutine is moved from one thread to another, the assu=
mption obviously does not hold. In fact it would be wrong for a coroutine t=
o preserve the thread status register. This means that coroutines put a con=
straint on compiler optimizations. This constraint should be mentioned. <br=
></div></blockquote><div><br>But this constraint is not special to coroutin=
es it applies to ordinary code too?!<br></div>

<p></p>

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

------=_Part_1185_27481530.1363608609056--

.

--047d7b2e1543e4e3aa04d8320201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2013 at 12:10 PM, Oliver Kowalke
<oliver.kowalke@gmail.com>wrote:

> Am Montag, 18. M=E4rz 2013 12:19:43 UTC+1 schrieb Giovanni Piero Deretta:
>
>> Some ABIs use a thread status register that it is used to refer to threa=
d
>> local storage. Compilers do assume that the value of this register is
>> preserved across function calls and optimize accordingly (for example
>> hoisting thread local storage address computations). If a coroutine is
>> moved from one thread to another, the assumption obviously does not hold=
..
>> In fact it would be wrong for a coroutine to preserve the thread status
>> register. This means that coroutines put a constraint on compiler
>> optimizations. This constraint should be mentioned.
>>
>
> But this constraint is not special to coroutines it applies to ordinary
> code too?!
>

No, ordinary (standard compliant) code cannot switch to another thread, so
the optimization is normally legal. These compilers do break code that use,
for example, POSIX swap_context for context switching. Note that the VC++
compiler has an (obscure) option to disable optimizations like thread local
storage address computation hoisting that would break with fibers, so it is
a real, known problem.

-- gpd

--=20

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



--047d7b2e1543e4e3aa04d8320201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Mar 18, 2013 at 12:10 PM, Oliver Kowalke=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:oliver.kowalke@gmail.com" target=
=3D"_blank">oliver.kowalke@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
Am Montag, 18. M=E4rz 2013 12:19:43 UTC+1 schrieb Giovanni Piero Deretta:<d=
iv class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Some ABIs use =
a thread status register that it is used to refer to thread local storage. =
Compilers do assume that the value of this register is preserved across fun=
ction calls and optimize accordingly (for example hoisting thread local sto=
rage address computations). If a coroutine is moved from one thread to anot=
her, the assumption obviously does not hold. In fact it would be wrong for =
a coroutine to preserve the thread status register. This means that corouti=
nes put a constraint on compiler optimizations. This constraint should be m=
entioned. <br>
</div></blockquote></div><div><br>But this constraint is not special to cor=
outines it applies to ordinary code too?!<br></div></blockquote><div><br>No=
, ordinary (standard compliant) code cannot switch to another thread, so th=
e optimization is normally legal. These compilers do break code that use, f=
or example, POSIX swap_context for context switching. Note that the VC++ co=
mpiler has an (obscure) option to disable optimizations like thread local s=
torage address computation hoisting that would break with fibers, so it is =
a real, known problem.<br>
<br>-- gpd<br></div></div><br>

<p></p>

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

--047d7b2e1543e4e3aa04d8320201--

.

------=_Part_295_12756171.1363610425394
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Montag, 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:

> No, ordinary (standard compliant) code cannot switch to another thread, s=
o=20
> the optimization is normally legal.
>

OK, I see that thread_local can have namespace-scope,  be a static class=20
data member and a local variable. The last one can be moved to other=20
threads via stack swapping and should not be used in the context of=20
coroutines if coroutine is migration to an other thread.

=20

--=20

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



------=_Part_295_12756171.1363610425394
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Montag, 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"><=
div>No, ordinary (standard compliant) code cannot switch to another thread,=
 so the optimization is normally legal.<br></div></div></blockquote><div><b=
r>OK, I see that thread_local can have namespace-scope,&nbsp; be a static c=
lass data member and a local variable. The last one can be moved to other t=
hreads via stack swapping and should not be used in the context of coroutin=
es if coroutine is migration to an other thread.<br></div><div><br>&nbsp;</=
div>

<p></p>

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

------=_Part_295_12756171.1363610425394--

.

--047d7b6d876e13aa3a04d832b4dc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2013 at 12:40 PM, Oliver Kowalke
<oliver.kowalke@gmail.com>wrote:

> Am Montag, 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:
>
> No, ordinary (standard compliant) code cannot switch to another thread, s=
o
>> the optimization is normally legal.
>>
>
> OK, I see that thread_local can have namespace-scope,  be a static class
> data member and a local variable. The last one can be moved to other
> threads via stack swapping and should not be used in the context of
> coroutines if coroutine is migration to an other thread.
>
>
Unfortunately automatic thread locals are not the issue. Consider errno,
usually a global, static per thread variable:
#include <ucontext.h>
#include <math.h>
#include <errno.h>

int print(const char*, int);

void foo(ucontext_t* self, ucontext_t* other)
{
    double x =3D sin(1.0);
    print("sin returned:", errno);
    swapcontext(self, other);
    x =3D cos(2.0);
    print("cos returned ", errno);

}

A recent GCC, with optimization enabled, compiles it down to this:

foo(ucontext*, ucontext*):
    movq    %rbx, -24(%rsp)
    movq    %rbp, -16(%rsp)
    movq    %rdi, %rbp
    movq    %r12, -8(%rsp)
    subq    $24, %rsp
    movq    %rsi, %r12
    movsd    .LC0(%rip), %xmm0
    call    sin
    call    __errno_location
    movl    (%rax), %esi
    movl    $.LC1, %edi
    movq    %rax, %rbx
    call    print(char const*, int)
    movq    %r12, %rsi
    movq    %rbp, %rdi
    call    swapcontext
    movsd    .LC2(%rip), %xmm0
    call    cos
    movl    (%rbx), %esi
    movq    8(%rsp), %rbp
    movl    $.LC3, %edi
    movq    (%rsp), %rbx
    movq    16(%rsp), %r12
    addq    $24, %rsp
    jmp    print(char const*, int)

Now, here errno doesn't directly use the thread pointer register (%fs on
this architecture), but does an external call to the (internal)
__errno_location, provided by the C runtime (as per ABI) to retrieve the
address of errno, which returns the current errno address in %rax. This
address is passed to print. Then swap context is called, which could
potentially move the context to another thread, invalidating the errno
address. Still, for the next call to print, __errno_location is not called
again; the previously computed address of errno, no longer current for this
thread, is reused.

As you can see, a simple and straight forward function already breaks when
errno is used. I could also show an example using an explicit thread_local
variable at namespace scope.

--=20

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



--047d7b6d876e13aa3a04d832b4dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Mar 18, 2013 at 12:40 PM, Oliver=
 Kowalke <span dir=3D"ltr">&lt;<a href=3D"mailto:oliver.kowalke@gmail.com" =
target=3D"_blank">oliver.kowalke@gmail.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
Am Montag, 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:<d=
iv class=3D"im"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"g=
mail_quote">
<div>No, ordinary (standard compliant) code cannot switch to another thread=
, so the optimization is normally legal.<br></div></div></blockquote></div>=
<div><br>OK, I see that thread_local can have namespace-scope,=A0 be a stat=
ic class data member and a local variable. The last one can be moved to oth=
er threads via stack swapping and should not be used in the context of coro=
utines if coroutine is migration to an other thread.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5"><div><br></div></div></div></=
blockquote><div><div></div><br>Unfortunately automatic thread locals are no=
t the issue. Consider errno, usually a global, static per thread variable:<=
br>
#include &lt;ucontext.h&gt;<br>#include &lt;math.h&gt;<br>#include &lt;errn=
o.h&gt;<br><br>int print(const char*, int);<br><br>void foo(ucontext_t* sel=
f, ucontext_t* other)<br>{<br>=A0=A0=A0 double x =3D sin(1.0);<br>=A0=A0=A0=
 print(&quot;sin returned:&quot;, errno);<br>
=A0=A0=A0 swapcontext(self, other);<br>=A0=A0=A0 x =3D cos(2.0);<br>=A0=A0=
=A0 print(&quot;cos returned &quot;, errno);<br><br>}<br><br>A recent GCC, =
with optimization enabled, compiles it down to this:<br><br>foo(ucontext*, =
ucontext*):<br>=A0=A0=A0 movq=A0=A0=A0 %rbx, -24(%rsp)<br>
=A0=A0=A0 movq=A0=A0=A0 %rbp, -16(%rsp)<br>=A0=A0=A0 movq=A0=A0=A0 %rdi, %r=
bp<br>=A0=A0=A0 movq=A0=A0=A0 %r12, -8(%rsp)<br>=A0=A0=A0 subq=A0=A0=A0 $24=
, %rsp<br>=A0=A0=A0 movq=A0=A0=A0 %rsi, %r12<br>=A0=A0=A0 movsd=A0=A0=A0 .L=
C0(%rip), %xmm0<br>=A0=A0=A0 call=A0=A0=A0 sin<br>=A0=A0=A0 call=A0=A0=A0 _=
_errno_location<br>
=A0=A0=A0 movl=A0=A0=A0 (%rax), %esi<br>=A0=A0=A0 movl=A0=A0=A0 $.LC1, %edi=
<br>=A0=A0=A0 movq=A0=A0=A0 %rax, %rbx<br>=A0=A0=A0 call=A0=A0=A0 print(cha=
r const*, int)<br>=A0=A0=A0 movq=A0=A0=A0 %r12, %rsi<br>=A0=A0=A0 movq=A0=
=A0=A0 %rbp, %rdi<br>=A0=A0=A0 call=A0=A0=A0 swapcontext<br>=A0=A0=A0 movsd=
=A0=A0=A0 .LC2(%rip), %xmm0<br>
=A0=A0=A0 call=A0=A0=A0 cos<br>=A0=A0=A0 movl=A0=A0=A0 (%rbx), %esi<br>=A0=
=A0=A0 movq=A0=A0=A0 8(%rsp), %rbp<br>=A0=A0=A0 movl=A0=A0=A0 $.LC3, %edi<b=
r>=A0=A0=A0 movq=A0=A0=A0 (%rsp), %rbx<br>=A0=A0=A0 movq=A0=A0=A0 16(%rsp),=
 %r12<br>=A0=A0=A0 addq=A0=A0=A0 $24, %rsp<br>=A0=A0=A0 jmp=A0=A0=A0 print(=
char const*, int)<br>
<br></div></div>Now, here errno doesn&#39;t directly use the thread pointer=
 register (%fs on this architecture), but does an external call to the (int=
ernal) __errno_location, provided by the C runtime (as per ABI) to retrieve=
 the address of errno, which returns the current errno address in %rax. Thi=
s address is passed to print. Then swap context is called, which could pote=
ntially move the context to another thread, invalidating the errno address.=
 Still, for the next call to print, __errno_location is not called again; t=
he previously computed address of errno, no longer current for this thread,=
 is reused.<br>
<br>As you can see, a simple and straight forward function already breaks w=
hen errno is used. I could also show an example using an explicit thread_lo=
cal variable at namespace scope.<br>

<p></p>

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

--047d7b6d876e13aa3a04d832b4dc--

.

--bcaec520efdd726bed04d832c1d7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 18, 2013 at 1:09 PM, Giovanni Piero Deretta <gpderetta@gmail.co=
m
> wrote:

>
>
> On Mon, Mar 18, 2013 at 12:40 PM, Oliver Kowalke <oliver.kowalke@gmail.co=
m
> > wrote:
>
>> Am Montag, 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta=
:
>>
>> No, ordinary (standard compliant) code cannot switch to another thread,
>>> so the optimization is normally legal.
>>>
>>
>> OK, I see that thread_local can have namespace-scope,  be a static class
>> data member and a local variable. The last one can be moved to other
>> threads via stack swapping and should not be used in the context of
>> coroutines if coroutine is migration to an other thread.
>>
>>
> Unfortunately automatic thread locals are not the issue. Consider errno,
> usually a global, static per thread variable:
> #include <ucontext.h>
> #include <math.h>
> #include <errno.h>
>
> int print(const char*, int);
>
> void foo(ucontext_t* self, ucontext_t* other)
> {
>     double x =3D sin(1.0);
>     print("sin returned:", errno);
>     swapcontext(self, other);
>     x =3D cos(2.0);
>     print("cos returned ", errno);
>
> }
>
> A recent GCC, with optimization enabled, compiles it down to this:
>
> foo(ucontext*, ucontext*):
>     movq    %rbx, -24(%rsp)
>     movq    %rbp, -16(%rsp)
>     movq    %rdi, %rbp
>     movq    %r12, -8(%rsp)
>     subq    $24, %rsp
>     movq    %rsi, %r12
>     movsd    .LC0(%rip), %xmm0
>     call    sin
>     call    __errno_location
>     movl    (%rax), %esi
>     movl    $.LC1, %edi
>     movq    %rax, %rbx
>     call    print(char const*, int)
>     movq    %r12, %rsi
>     movq    %rbp, %rdi
>     call    swapcontext
>     movsd    .LC2(%rip), %xmm0
>     call    cos
>     movl    (%rbx), %esi
>     movq    8(%rsp), %rbp
>     movl    $.LC3, %edi
>     movq    (%rsp), %rbx
>     movq    16(%rsp), %r12
>     addq    $24, %rsp
>     jmp    print(char const*, int)
>
> Now, here errno doesn't directly use the thread pointer register (%fs on
> this architecture), but does an external call to the (internal)
> __errno_location, provided by the C runtime (as per ABI) to retrieve the
> address of errno, which returns the current errno address in %rax. This
> address is passed to print.
>

The last sentence is obviously wrong (after writing the above sentence, I
had changed the signature of print to make it more realistic). The address
of errno is not passed to print, just the result of dereferencing it. The
issue still remain though.

-- gpd

--=20

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



--bcaec520efdd726bed04d832c1d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Mar 18, 2013 at 1:09 PM, Giovanni Piero =
Deretta <span dir=3D"ltr">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=
=3D"_blank">gpderetta@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<br><br><div class=3D"gmail_quote"><div class=3D"im">On Mon, Mar 18, 2013 a=
t 12:40 PM, Oliver Kowalke <span dir=3D"ltr">&lt;<a href=3D"mailto:oliver.k=
owalke@gmail.com" target=3D"_blank">oliver.kowalke@gmail.com</a>&gt;</span>=
 wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Am Montag, 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:<d=
iv><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote">
<div>No, ordinary (standard compliant) code cannot switch to another thread=
, so the optimization is normally legal.<br></div></div></blockquote></div>=
<div><br>OK, I see that thread_local can have namespace-scope,=A0 be a stat=
ic class data member and a local variable. The last one can be moved to oth=
er threads via stack swapping and should not be used in the context of coro=
utines if coroutine is migration to an other thread.<br>

</div><div><div><div><br></div></div></div></blockquote></div><div><div></d=
iv><br>Unfortunately automatic thread locals are not the issue. Consider er=
rno, usually a global, static per thread variable:<br>
#include &lt;ucontext.h&gt;<br>#include &lt;math.h&gt;<br>#include &lt;errn=
o.h&gt;<br><br>int print(const char*, int);<br><br>void foo(ucontext_t* sel=
f, ucontext_t* other)<br>{<br>=A0=A0=A0 double x =3D sin(1.0);<br>=A0=A0=A0=
 print(&quot;sin returned:&quot;, errno);<br>

=A0=A0=A0 swapcontext(self, other);<br>=A0=A0=A0 x =3D cos(2.0);<br>=A0=A0=
=A0 print(&quot;cos returned &quot;, errno);<br><br>}<br><br>A recent GCC, =
with optimization enabled, compiles it down to this:<br><br>foo(ucontext*, =
ucontext*):<br>=A0=A0=A0 movq=A0=A0=A0 %rbx, -24(%rsp)<br>

=A0=A0=A0 movq=A0=A0=A0 %rbp, -16(%rsp)<br>=A0=A0=A0 movq=A0=A0=A0 %rdi, %r=
bp<br>=A0=A0=A0 movq=A0=A0=A0 %r12, -8(%rsp)<br>=A0=A0=A0 subq=A0=A0=A0 $24=
, %rsp<br>=A0=A0=A0 movq=A0=A0=A0 %rsi, %r12<br>=A0=A0=A0 movsd=A0=A0=A0 .L=
C0(%rip), %xmm0<br>=A0=A0=A0 call=A0=A0=A0 sin<br>=A0=A0=A0 call=A0=A0=A0 _=
_errno_location<br>

=A0=A0=A0 movl=A0=A0=A0 (%rax), %esi<br>=A0=A0=A0 movl=A0=A0=A0 $.LC1, %edi=
<br>=A0=A0=A0 movq=A0=A0=A0 %rax, %rbx<br>=A0=A0=A0 call=A0=A0=A0 print(cha=
r const*, int)<br>=A0=A0=A0 movq=A0=A0=A0 %r12, %rsi<br>=A0=A0=A0 movq=A0=
=A0=A0 %rbp, %rdi<br>=A0=A0=A0 call=A0=A0=A0 swapcontext<br>=A0=A0=A0 movsd=
=A0=A0=A0 .LC2(%rip), %xmm0<br>

=A0=A0=A0 call=A0=A0=A0 cos<br>=A0=A0=A0 movl=A0=A0=A0 (%rbx), %esi<br>=A0=
=A0=A0 movq=A0=A0=A0 8(%rsp), %rbp<br>=A0=A0=A0 movl=A0=A0=A0 $.LC3, %edi<b=
r>=A0=A0=A0 movq=A0=A0=A0 (%rsp), %rbx<br>=A0=A0=A0 movq=A0=A0=A0 16(%rsp),=
 %r12<br>=A0=A0=A0 addq=A0=A0=A0 $24, %rsp<br>=A0=A0=A0 jmp=A0=A0=A0 print(=
char const*, int)<br>

<br></div></div>Now, here errno doesn&#39;t directly use the thread pointer=
 register (%fs on this architecture), but does an external call to the (int=
ernal) __errno_location, provided by the C runtime (as per ABI) to retrieve=
 the address of errno, which returns the current errno address in %rax. Thi=
s address is passed to print.<br>
</blockquote></div><br>The last sentence is obviously wrong (after writing =
the above sentence, I had changed the signature of print to make it more re=
alistic). The address of errno is not passed to print, just the result of d=
ereferencing it. The issue still remain though.<br>
<br>-- gpd<br><br><br>

<p></p>

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

--bcaec520efdd726bed04d832c1d7--

.

On 3/15/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> this is the first version of the proposal to add coroutines to C++.
> The pdf can be found here: http://ok73.funpic.de/coroutine.pdf

Could you make a comparison to other coroutine libraries?
For example, the original task library has been abandoned.  Why?
What does your proposal do differently?

http://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_2.0/doc/LibraryManual.pdf

--
Lawrence Crowl

--

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



.

------=_Part_153_13849340.1363641617934
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Montag, 18. M=E4rz 2013 21:24:06 UTC+1 schrieb Lawrence Crowl:
>
> On 3/15/13, Oliver Kowalke <oliver....@gmail.com <javascript:>> wrote:=20
> > this is the first version of the proposal to add coroutines to C++.=20
> > The pdf can be found here: http://ok73.funpic.de/coroutine.pdf=20
>
> Could you make a comparison to other coroutine libraries?=20
> For example, the original task library has been abandoned.  Why?=20
> What does your proposal do differently?


I wasn't aware of the original task library.

In my opinion std::coroutine<> should be used escape-and-reenter of loops=
=20
and recursive computations (special/enhanced kind of control flow).
Of course you could use std::coroutine<> as basis for cooperative=20
multitasking but this involves scheduling
and synchronization primitives etc. For cooperative multitasking I suggest=
=20
to use a different kind of object - fibers (see boost.fiber).
A fiber has the same interface as std::thread (with mutex, condition-var,=
=20
future, async() ...) but provides cooperative mutlitasking (no inversion of=
=20
control).

The proposal does not introduce scheduling of coroutines - in my opinion=20
this is not in the context of coroutines.

Giovanni already mentioned that it might be better to add fibers to the=20
proposal too. The question to be answered is how coroutines and fibers=20
interact with threads async/futures etc.

In short: fiber -> concurrency, coroutines -> enahnced control flow, thread=
=20
-> parallelism ...=20

--=20

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



------=_Part_153_13849340.1363641617934
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Montag, 18. M=E4rz 2013 21:24:06 UTC+1 schrieb Lawrence Crowl:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">On 3/15/13, Oliver Kowalke &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"h3TKhJ13MyMJ">o=
liver....@gmail.com</a>&gt; wrote:
<br>&gt; this is the first version of the proposal to add coroutines to C++=
..
<br>&gt; The pdf can be found here: <a href=3D"http://ok73.funpic.de/corout=
ine.pdf" target=3D"_blank">http://ok73.funpic.de/<wbr>coroutine.pdf</a>
<br>
<br>Could you make a comparison to other coroutine libraries?
<br>For example, the original task library has been abandoned. &nbsp;Why?
<br>What does your proposal do differently?</blockquote><div><br>I wasn't a=
ware of the original task library.<br><br>In my opinion std::coroutine&lt;&=
gt; should be used escape-and-reenter of loops and recursive computations (=
special/enhanced kind of control flow).<br>Of course you could use std::cor=
outine&lt;&gt; as basis for cooperative multitasking but this involves sche=
duling<br>and synchronization primitives etc. For cooperative multitasking =
I suggest to use a different kind of object - fibers (see boost.fiber).<br>=
A fiber has the same interface as std::thread (with mutex, condition-var, f=
uture, async() ...) but provides cooperative mutlitasking (no inversion of =
control).<br><br>The proposal does not introduce scheduling of coroutines -=
 in my opinion this is not in the context of coroutines.<br><br>Giovanni al=
ready mentioned that it might be better to add fibers to the proposal too. =
The question to be answered is how coroutines and fibers interact with thre=
ads async/futures etc.<br><br>In short: fiber -&gt; concurrency, coroutines=
 -&gt; enahnced control flow, thread -&gt; parallelism ... <br></div><div s=
tyle=3D"display: none;" id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"><=
/div>

<p></p>

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

------=_Part_153_13849340.1363641617934--

.

------=_Part_1330_14222502.1363670000712
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On Monday, March 18, 2013 9:40:25 PM UTC+9, Oliver Kowalke wrote:
>
> Am Montag, 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:
>
>> No, ordinary (standard compliant) code cannot switch to another thread,=
=20
>> so the optimization is normally legal.
>>
>
> OK, I see that thread_local can have namespace-scope,  be a static class=
=20
> data member and a local variable. The last one can be moved to other=20
> threads via stack swapping and should not be used in the context of=20
> coroutines if coroutine is migration to an other thread.
>
> =20
>

have you read=20
http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_threa=
d.html=20
? Not only automatic thread local variables but any kinds of thread local=
=20
variables might become problematic if a coroutine migrates between threads.

I think that our only option is to specify "a coroutine should not migrate=
=20
between multiple threads." The wording like "thread-local storage should=20
not be used if a coroutine migrates between threads" eventually prohibits=
=20
any use of functions and classes of which the implementation detail is not=
=20
known to us. Functions and classes might use thread-local storage as their=
=20
internal implementation detail. In theory, even an implementation of=20
std::vector is allowed to use thread-local storage internally for any=20
purpose. Therefore, as far as strict compliance with the specification is=
=20
concerned, std::vector cannot be used in a coroutine if the coroutine=20
migrates between threads. This is pretty much the same as the conclusion=20
that a coroutine should not migrate between threads.

On the other hand, I completely agree that this is awfully restrictive. I=
=20
am really interested in using coroutines with reactor/proactor frameworks.=
=20
For the reason I mentioned above, only one thread can be put into the event=
=20
loop in boost::asio::io_service if a coroutine is used as an event handler=
=20
for Boost.Asio. If the restriction were solved, we could put multiple=20
threads into the event loop and take full advantage of hardware concurrency=
..

However, I think that the most fundamental way to overcome this restriction=
=20
is to extend the C++ memory models...

--=20

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



------=_Part_1330_14222502.1363670000712
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>On Monday, March 18, 2013 9:40:25 PM UTC+9, Oliver Kowalke wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">Am Montag, 18. M=E4rz 2013 13=
:20:15 UTC+1 schrieb Giovanni Piero Deretta:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div class=3D"gmail_quote"><div>No, ordinary (standard complia=
nt) code cannot switch to another thread, so the optimization is normally l=
egal.<br></div></div></blockquote><div><br>OK, I see that thread_local can =
have namespace-scope,&nbsp; be a static class data member and a local varia=
ble. The last one can be moved to other threads via stack swapping and shou=
ld not be used in the context of coroutines if coroutine is migration to an=
 other thread.<br></div><div><br>&nbsp;</div></blockquote><div><br></div><d=
iv>have you read http://www.crystalclearsoftware.com/soc/coroutine/coroutin=
e/coroutine_thread.html ? Not only automatic thread local variables but any=
 kinds of thread local variables might become problematic if a coroutine mi=
grates between threads.</div><div><br></div><div>I think that our only opti=
on is to specify "a coroutine should not migrate between multiple threads."=
 The wording like "thread-local storage should not be used if a coroutine m=
igrates between threads" eventually prohibits any use of functions and clas=
ses of which the implementation detail is not known to us. Functions and cl=
asses might use thread-local storage as their internal implementation detai=
l. In theory, even an implementation of std::vector is allowed to use threa=
d-local storage internally for any purpose. Therefore, as far as strict com=
pliance with the specification is concerned, std::vector cannot be used in =
a coroutine if the coroutine migrates between threads. This is pretty much =
the same as the conclusion that a coroutine should not migrate between thre=
ads.</div><div><br></div><div>On the other hand, I completely agree that th=
is is awfully restrictive. I am really interested in using coroutines with =
reactor/proactor frameworks. For the reason I mentioned above, only one thr=
ead can be put into the event loop in boost::asio::io_service if a coroutin=
e is used as an event handler for Boost.Asio. If the restriction were solve=
d, we could put multiple threads into the event loop and take full advantag=
e of hardware concurrency.</div><div><br></div><div>However, I think that t=
he most fundamental way to overcome this restriction is to extend the C++ m=
emory models...</div><div><br></div>

<p></p>

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

------=_Part_1330_14222502.1363670000712--

.

------=_Part_2165_10767672.1363678202679
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Dienstag, 19. M=E4rz 2013 06:13:20 UTC+1 schrieb ai.a...@gmail.com:
>
>
> I think that our only option is to specify "a coroutine should not migrat=
e=20
> between multiple threads." The wording like "thread-local storage should=
=20
> not be used if a coroutine migrates between threads" eventually prohibits=
=20
> any use of functions and classes of which the implementation detail is no=
t=20
> known to us. Functions and classes might use thread-local storage as thei=
r=20
> internal implementation detail. In theory, even an implementation of=20
> std::vector is allowed to use thread-local storage internally for any=20
> purpose. Therefore, as far as strict compliance with the specification is=
=20
> concerned, std::vector cannot be used in a coroutine if the coroutine=20
> migrates between threads. This is pretty much the same as the conclusion=
=20
> that a coroutine should not migrate between threads.
>

I thought follwoing code would be still correct, isn't it?!

class scheduler
{
static thread_local X * x_;

 static void construct( X *x) {
    x_ =3D x;
  }
  X * instance() {
   return x_;
}
};

void fn1() {
   scheduler::construct( new MyX() );
   scheduler::instance()->abc();
 }

fn1() is the thread-function (passed to std::thread ctor) coroutines=20
accessing scheduler::instance() should get the instance of X* which was=20
created in the thread-function even if coroutines migrate between threads.
At least my understanding of thread_local was that this pattern is legal.

--=20

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



------=_Part_2165_10767672.1363678202679
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Dienstag, 19. M=E4rz 2013 06:13:20 UTC+1 schrieb ai.a...@gmail.com:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div><br></div><div></div><div>I th=
ink that our only option is to specify "a coroutine should not migrate betw=
een multiple threads." The wording like "thread-local storage should not be=
 used if a coroutine migrates between threads" eventually prohibits any use=
 of functions and classes of which the implementation detail is not known t=
o us. Functions and classes might use thread-local storage as their interna=
l implementation detail. In theory, even an implementation of std::vector i=
s allowed to use thread-local storage internally for any purpose. Therefore=
, as far as strict compliance with the specification is concerned, std::vec=
tor cannot be used in a coroutine if the coroutine migrates between threads=
.. This is pretty much the same as the conclusion that a coroutine should no=
t migrate between threads.</div></blockquote><div><br>I thought follwoing c=
ode would be still correct, isn't it?!<br><br>class scheduler<br>{<br>stati=
c thread_local X * x_;<br><br>&nbsp;static void construct( X *x) {<br>&nbsp=
;&nbsp;&nbsp; x_ =3D x;<br>&nbsp; }<br>&nbsp; X * instance() {<br>&nbsp;&nb=
sp; return x_;<br>}<br>};<br><br>void fn1() {<br>&nbsp;&nbsp; scheduler::co=
nstruct( new MyX() );<br>&nbsp;&nbsp; scheduler::instance()-&gt;abc();<br>&=
nbsp;}<br><br>fn1() is the thread-function (passed to std::thread ctor) cor=
outines accessing scheduler::instance() should get the instance of X* which=
 was created in the thread-function even if coroutines migrate between thre=
ads.<br>At least my understanding of thread_local was that this pattern is =
legal.</div>

<p></p>

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

------=_Part_2165_10767672.1363678202679--

.

--bcaec520efdd7a054a04d843e6fd
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 19, 2013 at 5:13 AM, <ai.azuma@gmail.com> wrote:

> Hi,
>
>
> On Monday, March 18, 2013 9:40:25 PM UTC+9, Oliver Kowalke wrote:
>>
>> Am Montag, 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta=
:
>>
>>> No, ordinary (standard compliant) code cannot switch to another thread,
>>> so the optimization is normally legal.
>>>
>>
>> OK, I see that thread_local can have namespace-scope,  be a static class
>> data member and a local variable. The last one can be moved to other
>> threads via stack swapping and should not be used in the context of
>> coroutines if coroutine is migration to an other thread.
>>
>>
>>
>
> have you read
> http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_thr=
ead.html? Not only automatic thread local variables but any kinds of thread=
 local
> variables might become problematic if a coroutine migrates between thread=
s.
>
> I think that our only option is to specify "a coroutine should not migrat=
e
> between multiple threads."
>

No, the right solution is to require compilers to do the right thing and
not break code by not assuming that thread_local addresses are invariant
across function calls. Now whether the paper should ask for coroutine local
storage or not is another story. The safe solution might be to require
thread_local storage to be coroutine-local, but this might make coroutine
creation much heavier. Note that there is already the issue on whether on a
pool based async should thread_local storage be task local or survive the
task. The issue with coroutines is not completely unlike (with the
additional problem that lifetimes may overlap).


> The wording like "thread-local storage should not be used if a coroutine
> migrates between threads" eventually prohibits any use of functions and
> classes of which the implementation detail is not known to us. Functions
> and classes might use thread-local storage as their internal implementati=
on
> detail. In theory, even an implementation of std::vector is allowed to us=
e
> thread-local storage internally for any purpose. Therefore, as far as
> strict compliance with the specification is concerned, std::vector cannot
> be used in a coroutine if the coroutine migrates between threads. This is
> pretty much the same as the conclusion that a coroutine should not migrat=
e
> between threads.
>

exactly. For example the use of errno is pervasive, and it is thread local.

-- gpd

--=20

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



--bcaec520efdd7a054a04d843e6fd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Mar 19, 2013 at 5:13 AM,  <span dir=3D"l=
tr">&lt;<a href=3D"mailto:ai.azuma@gmail.com" target=3D"_blank">ai.azuma@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<div class=3D"im"><br><br>On Monday, March 18, 2013 9:40:25 PM UTC+9, Ol=
iver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Am Montag, 18. M=
=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div>No,=
 ordinary (standard compliant) code cannot switch to another thread, so the=
 optimization is normally legal.<br>
</div></div></blockquote><div><br>OK, I see that thread_local can have name=
space-scope,=A0 be a static class data member and a local variable. The las=
t one can be moved to other threads via stack swapping and should not be us=
ed in the context of coroutines if coroutine is migration to an other threa=
d.<br>
</div><div><br>=A0</div></blockquote><div><br></div></div><div>have you rea=
d <a href=3D"http://www.crystalclearsoftware.com/soc/coroutine/coroutine/co=
routine_thread.html" target=3D"_blank">http://www.crystalclearsoftware.com/=
soc/coroutine/coroutine/coroutine_thread.html</a> ? Not only automatic thre=
ad local variables but any kinds of thread local variables might become pro=
blematic if a coroutine migrates between threads.</div>
<div><br></div><div>I think that our only option is to specify &quot;a coro=
utine should not migrate between multiple threads.&quot;</div></blockquote>=
<div><br>No, the right solution is to require compilers to do the right thi=
ng and not break code by not assuming that thread_local addresses are invar=
iant across function calls. Now whether the paper should ask for coroutine =
local storage or not is another story. The safe solution might be to requir=
e thread_local storage to be coroutine-local, but this might make coroutine=
 creation much heavier. Note that there is already the issue on whether on =
a pool based async should thread_local storage be task local or survive the=
 task. The issue with coroutines is not completely unlike (with the additio=
nal problem that lifetimes may overlap).<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div> The wording like &quot;thread=
-local storage should not be used if a coroutine migrates between threads&q=
uot; eventually prohibits any use of functions and classes of which the imp=
lementation detail is not known to us. Functions and classes might use thre=
ad-local storage as their internal implementation detail. In theory, even a=
n implementation of std::vector is allowed to use thread-local storage inte=
rnally for any purpose. Therefore, as far as strict compliance with the spe=
cification is concerned, std::vector cannot be used in a coroutine if the c=
oroutine migrates between threads. This is pretty much the same as the conc=
lusion that a coroutine should not migrate between threads.</div>
</blockquote><div><br>exactly. For example the use of errno is pervasive, a=
nd it is thread local. <br></div></div><br>-- gpd<br>

<p></p>

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

--bcaec520efdd7a054a04d843e6fd--

.

On 3/19/13, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
> On Mar 19, 2013 <ai.azuma@gmail.com> wrote:
> > On March 18, 2013 9:40:25 PM UTC+9, Oliver Kowalke wrote:
> > > Am 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:
> > > > No, ordinary (standard compliant) code cannot switch to
> > > > another thread, so the optimization is normally legal.
> > >
> > > OK, I see that thread_local can have namespace-scope, be a
> > > static class data member and a local variable. The last one
> > > can be moved to other threads via stack swapping and should
> > > not be used in the context of coroutines if coroutine is
> > > migration to an other thread.
> >
> > have you read
> > http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_t=
hread.html?
> > Not only automatic thread local variables but any kinds of
> > thread local variables might become problematic if a coroutine
> > migrates between threads.
> >
> > I think that our only option is to specify "a coroutine should
> > not migrate between multiple threads."
>
> No, the right solution is to require compilers to do the right
> thing and not break code by not assuming that thread_local
> addresses are invariant across function calls. Now whether the
> paper should ask for coroutine local storage or not is another
> story. The safe solution might be to require thread_local storage
> to be coroutine-local, but this might make coroutine creation
> much heavier. Note that there is already the issue on whether
> on a pool based async should thread_local storage be task local
> or survive the task. The issue with coroutines is not completely
> unlike (with the additional problem that lifetimes may overlap).
>
> > The wording like "thread-local storage should not be used if
> > a coroutine migrates between threads" eventually prohibits
> > any use of functions and classes of which the implementation
> > detail is not known to us. Functions and classes might use
> > thread-local storage as their internal implementation detail. In
> > theory, even an implementation of std::vector is allowed to use
> > thread-local storage internally for any purpose. Therefore, as
> > far as strict compliance with the specification is concerned,
> > std::vector cannot be used in a coroutine if the coroutine
> > migrates between threads. This is pretty much the same as the
> > conclusion that a coroutine should not migrate between threads.
>
> exactly. For example the use of errno is pervasive, and it is
> thread local.

If coroutines are only migrated between theads at explicit points
in the code, then coroutines can freely use thread_local variables
as caches on global state.  For example, memory allocators may
use thread local_variables to keep a pool of memory that can be
managed without locks.  What programs using coroutines cannot do
is use thread_local variables as persistent state distinct from
global state.

It would be possible to simply state this property as a global
restriction.  That places a burden on the programmer using coroutines
to not call libraries that are sensitive to thread identity or that
switch coroutines.  How is this burden any different from asking
libraries to be data-race free?

--=20
Lawrence Crowl

--=20

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



.

* Oliver Kowalke:

> If you execute coroutines using thread-local storage then the code
> should work as usual code (without coroutines).

Right now, the programmer (or the compiler) can take the address of a
thread-local variable, call some functions, and be sure that after
those function calls, the pointer still points to the thread-local
object.

With coroutines, some one of the called functions can yield,
suspending the call stack.  Afterwards, execution can be resumed from
another thread.  The pointer still points to the original thread-local
object, which now belongs to another thread, not the current one.

> If you migrate coroutines using thread-local storage between threads
> then the same restrictions as for usual code should apply.

The problem here is that migration to another thread is a non-local
property which can be triggered by callback functions, for instance.
The ability to compose things this way is the point of coroutines.

--

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



.

--047d7b10cc358a0c7204d862a16f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2013 at 8:22 PM, Lawrence Crowl <crowl@googlers.com> wrote:

> On 3/19/13, Giovanni Piero Deretta <gpderetta@gmail.com> wrote:
> > On Mar 19, 2013 <ai.azuma@gmail.com> wrote:
> > > On March 18, 2013 9:40:25 PM UTC+9, Oliver Kowalke wrote:
> > > > Am 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Deretta:
> > > > > No, ordinary (standard compliant) code cannot switch to
> > > > > another thread, so the optimization is normally legal.
> > > >
> > > > OK, I see that thread_local can have namespace-scope, be a
> > > > static class data member and a local variable. The last one
> > > > can be moved to other threads via stack swapping and should
> > > > not be used in the context of coroutines if coroutine is
> > > > migration to an other thread.
> > >
> > > have you read
> > >
> http://www.crystalclearsoftware.com/soc/coroutine/coroutine/coroutine_thr=
ead.html
> ?
> > > Not only automatic thread local variables but any kinds of
> > > thread local variables might become problematic if a coroutine
> > > migrates between threads.
> > >
> > > I think that our only option is to specify "a coroutine should
> > > not migrate between multiple threads."
> >
> > No, the right solution is to require compilers to do the right
> > thing and not break code by not assuming that thread_local
> > addresses are invariant across function calls. Now whether the
> > paper should ask for coroutine local storage or not is another
> > story. The safe solution might be to require thread_local storage
> > to be coroutine-local, but this might make coroutine creation
> > much heavier. Note that there is already the issue on whether
> > on a pool based async should thread_local storage be task local
> > or survive the task. The issue with coroutines is not completely
> > unlike (with the additional problem that lifetimes may overlap).
> >
> > > The wording like "thread-local storage should not be used if
> > > a coroutine migrates between threads" eventually prohibits
> > > any use of functions and classes of which the implementation
> > > detail is not known to us. Functions and classes might use
> > > thread-local storage as their internal implementation detail. In
> > > theory, even an implementation of std::vector is allowed to use
> > > thread-local storage internally for any purpose. Therefore, as
> > > far as strict compliance with the specification is concerned,
> > > std::vector cannot be used in a coroutine if the coroutine
> > > migrates between threads. This is pretty much the same as the
> > > conclusion that a coroutine should not migrate between threads.
> >
> > exactly. For example the use of errno is pervasive, and it is
> > thread local.
>
> If coroutines are only migrated between theads at explicit points
> in the code, then coroutines can freely use thread_local variables
> as caches on global state.  For example, memory allocators may
> use thread local_variables to keep a pool of memory that can be
> managed without locks.  What programs using coroutines cannot do
> is use thread_local variables as persistent state distinct from
> global state.
>
> It would be possible to simply state this property as a global
> restriction.  That places a burden on the programmer using coroutines
> to not call libraries that are sensitive to thread identity or that
> switch coroutines.  How is this burden any different from asking
> libraries to be data-race free?
>

that's a perfectly reasonable restriction, i.e. do not assume that
thread_local values is persistent across function calls. My point, as shown
by my example, is that current compiler optimizers (as opposed to user
code) assume that thread_local *addresses* are invariant across function
calls. No matter how careful a programmer is, his code can still be broken
by a too aggressive optimizer. A coroutine proposal must explicitly
prohibit such an optimization.

-- gpd

--=20

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



--047d7b10cc358a0c7204d862a16f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Mar 20, 2013 at 8:22 PM, Lawrence Crowl =
<span dir=3D"ltr">&lt;<a href=3D"mailto:crowl@googlers.com" target=3D"_blan=
k">crowl@googlers.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">

On 3/19/13, Giovanni Piero Deretta &lt;<a href=3D"mailto:gpderetta@gmail.co=
m" target=3D"_blank">gpderetta@gmail.com</a>&gt; wrote:<br>
&gt; On Mar 19, 2013 &lt;<a href=3D"mailto:ai.azuma@gmail.com" target=3D"_b=
lank">ai.azuma@gmail.com</a>&gt; wrote:<br>
&gt; &gt; On March 18, 2013 9:40:25 PM UTC+9, Oliver Kowalke wrote:<br>
&gt; &gt; &gt; Am 18. M=E4rz 2013 13:20:15 UTC+1 schrieb Giovanni Piero Der=
etta:<br>
<div><div>&gt; &gt; &gt; &gt; No, ordinary (standard compliant) code cannot=
 switch to<br>
&gt; &gt; &gt; &gt; another thread, so the optimization is normally legal.<=
br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; OK, I see that thread_local can have namespace-scope, be a<b=
r>
&gt; &gt; &gt; static class data member and a local variable. The last one<=
br>
&gt; &gt; &gt; can be moved to other threads via stack swapping and should<=
br>
&gt; &gt; &gt; not be used in the context of coroutines if coroutine is<br>
&gt; &gt; &gt; migration to an other thread.<br>
&gt; &gt;<br>
&gt; &gt; have you read<br>
&gt; &gt; <a href=3D"http://www.crystalclearsoftware.com/soc/coroutine/coro=
utine/coroutine_thread.html" target=3D"_blank">http://www.crystalclearsoftw=
are.com/soc/coroutine/coroutine/coroutine_thread.html</a>?<br>
&gt; &gt; Not only automatic thread local variables but any kinds of<br>
&gt; &gt; thread local variables might become problematic if a coroutine<br=
>
&gt; &gt; migrates between threads.<br>
&gt; &gt;<br>
&gt; &gt; I think that our only option is to specify &quot;a coroutine shou=
ld<br>
&gt; &gt; not migrate between multiple threads.&quot;<br>
&gt;<br>
&gt; No, the right solution is to require compilers to do the right<br>
&gt; thing and not break code by not assuming that thread_local<br>
&gt; addresses are invariant across function calls. Now whether the<br>
&gt; paper should ask for coroutine local storage or not is another<br>
&gt; story. The safe solution might be to require thread_local storage<br>
&gt; to be coroutine-local, but this might make coroutine creation<br>
&gt; much heavier. Note that there is already the issue on whether<br>
&gt; on a pool based async should thread_local storage be task local<br>
&gt; or survive the task. The issue with coroutines is not completely<br>
&gt; unlike (with the additional problem that lifetimes may overlap).<br>
&gt;<br>
&gt; &gt; The wording like &quot;thread-local storage should not be used if=
<br>
&gt; &gt; a coroutine migrates between threads&quot; eventually prohibits<b=
r>
&gt; &gt; any use of functions and classes of which the implementation<br>
&gt; &gt; detail is not known to us. Functions and classes might use<br>
&gt; &gt; thread-local storage as their internal implementation detail. In<=
br>
&gt; &gt; theory, even an implementation of std::vector is allowed to use<b=
r>
&gt; &gt; thread-local storage internally for any purpose. Therefore, as<br=
>
&gt; &gt; far as strict compliance with the specification is concerned,<br>
&gt; &gt; std::vector cannot be used in a coroutine if the coroutine<br>
&gt; &gt; migrates between threads. This is pretty much the same as the<br>
&gt; &gt; conclusion that a coroutine should not migrate between threads.<b=
r>
&gt;<br>
&gt; exactly. For example the use of errno is pervasive, and it is<br>
&gt; thread local.<br>
<br>
</div></div>If coroutines are only migrated between theads at explicit poin=
ts<br>
in the code, then coroutines can freely use thread_local variables<br>
as caches on global state. =A0For example, memory allocators may<br>
use thread local_variables to keep a pool of memory that can be<br>
managed without locks. =A0What programs using coroutines cannot do<br>
is use thread_local variables as persistent state distinct from<br>
global state.<br>
<br>
It would be possible to simply state this property as a global<br>
restriction. =A0That places a burden on the programmer using coroutines<br>
to not call libraries that are sensitive to thread identity or that<br>
switch coroutines. =A0How is this burden any different from asking<br>
libraries to be data-race free?<br></blockquote><div><br>that&#39;s a perfe=
ctly reasonable restriction, i.e. do not assume that thread_local values is=
 persistent across function calls. My point, as shown by my example, is tha=
t current compiler optimizers (as opposed to user code) assume that thread_=
local *addresses* are invariant across function calls. No matter how carefu=
l a programmer is, his code can still be broken by a too aggressive optimiz=
er. A coroutine proposal must explicitly prohibit such an optimization.<br>
<br>-- gpd<br>
=A0</div></div><br>

<p></p>

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

--047d7b10cc358a0c7204d862a16f--

.

--e89a8fb20346d0e78f04d869ea43
Content-Type: text/plain; charset=ISO-8859-1

I was thinking on code using thread_local like this way and I assume its
legal:

struct Y {...};
struxt Z : public Y {...};

struct X
{
   thread_local static Y * y;
   static Y* instance() {
     return y;
   }
   static Y* set( Y * y_) {
      Y * tmp = y;
      y = y_;
      return tmp;
  }
};

void coro_fn( coroutine<> & c) {
   X::instance()->abc(); // call Y installed at this thread
  ....
}

void thread_fn() {
   Y * old = X::set( new Z() );
   coroutine<> c( coro_fn);
   ...
}

thread_fn() is executed by each thread installing its own Y as thread_local
static member of X.
each coroutine can access the instance of Y installed on the thread it is
running on - if the coroutine
is migrated to another thread (executing thread_fn() ) then it should get
another Y - 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--e89a8fb20346d0e78f04d869ea43
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I was thinking on code using thread_local like this way and I assume its le=
gal:<br><br>struct Y {...};<br>struxt Z : public Y {...};<br><br>struct X<b=
r>{<br>=A0=A0 thread_local static Y * y;<br>=A0=A0 static Y* instance() {<b=
r>=A0=A0=A0=A0 return y;<br>
=A0=A0 }<br>=A0=A0 static Y* set( Y * y_) {<br>=A0=A0=A0=A0=A0 Y * tmp =3D =
y;<br>=A0=A0=A0=A0=A0 y =3D y_;<br>=A0=A0=A0=A0=A0 return tmp;<br>=A0 }<br>=
};<br><br>void coro_fn( coroutine&lt;&gt; &amp; c) {<br>=A0=A0 X::instance(=
)-&gt;abc(); // call Y installed at this thread<br>
=A0 ....<br>}<br><br>void thread_fn() {<br>=A0=A0 Y * old =3D X::set( new Z=
() );<br>=A0=A0 coroutine&lt;&gt; c( coro_fn);<br>=A0=A0 ...<br>}<br><br>th=
read_fn() is executed by each thread installing its own Y as thread_local s=
tatic member of X.<br>
each coroutine can access the instance of Y installed on the thread it is r=
unning on - if the coroutine<br>is migrated to another thread (executing th=
read_fn() ) then it should get another Y - or not?!<br>

<p></p>

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

--e89a8fb20346d0e78f04d869ea43--

.

------=_Part_1187_18943754.1363849472863
Content-Type: text/plain; charset=ISO-8859-1

Y * X::y = 0; // was missing

X == scheduler
Y == abstract interface of scheduling algorithm
Z = concrete implementation of Y


--

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



------=_Part_1187_18943754.1363849472863
Content-Type: text/html; charset=ISO-8859-1

Y * X::y = 0; // was missing<br><br>X == scheduler<br>Y == abstract interface of scheduling algorithm<br>Z = concrete implementation of Y<br><br><br>

<p></p>

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

------=_Part_1187_18943754.1363849472863--

.

On Thu, Mar 21, 2013 at 7:02 AM, Oliver Kowalke
<oliver.kowalke@gmail.com> wrote:
> I was thinking on code using thread_local like this way and I assume its
> legal:
>
> struct Y {...};
> struxt Z : public Y {...};
>
> struct X
> {
>    thread_local static Y * y;
>    static Y* instance() {
>      return y;
>    }
>    static Y* set( Y * y_) {
>       Y * tmp = y;
>       y = y_;
>       return tmp;
>   }
> };
>
> void coro_fn( coroutine<> & c) {
>    X::instance()->abc(); // call Y installed at this thread
>   ....
> }
>
> void thread_fn() {
>    Y * old = X::set( new Z() );
>    coroutine<> c( coro_fn);
>    ...
> }
>
> thread_fn() is executed by each thread installing its own Y as thread_local
> static member of X.
> each coroutine can access the instance of Y installed on the thread it is
> running on - if the coroutine
> is migrated to another thread (executing thread_fn() ) then it should get
> another Y - or not?!

It should, but there is no guarantee, although a compiler is very
unlikely to break this specific example. This is likely to break
though:

void coro_fn( coroutine<> & c) {
   X::instance()->abc(); // call Y installed at this thread

   c(); // switches to a new thread
   ....

   X::instance()->abc(); // may call the Y installed at this thread or
the previous one, depending on the phase of the moon.

}


>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3g6ZIWedGJ8/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>

--

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



.

--e89a8fb20546c0932b04d86c75b6
Content-Type: text/plain; charset=ISO-8859-1

2013/3/21 Giovanni Piero Deretta <gpderetta@gmail.com>

>    X::instance()->abc(); // may call the Y installed at this thread or
> the previous one, depending on the phase of the moon.
>

why should it break? X::instance() access the thread_local static class
member 'y'. my understanding was that if I access 'y' I get the address
stored by the current thread (in its TLS).
if the code (not necessary a coroutine) is migrated to another thread 'y'
returns another value.
do you have a more detailed explanation why it could break?

--

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



--e89a8fb20546c0932b04d86c75b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2013/3/21 Giovanni Piero Deretta <span dir=3D"lt=
r">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@g=
mail.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=A0=A0 X::instance()-&gt;abc(); // may call the Y installed at this thread =
or<br>
the previous one, depending on the phase of the moon.<br></blockquote></div=
><br>why should it break? X::instance() access the thread_local static clas=
s member &#39;y&#39;. my understanding was that if I access &#39;y&#39; I g=
et the address stored by the current thread (in its TLS).<br>
if the code (not necessary a coroutine) is migrated to another thread &#39;=
y&#39; returns another value.<br>do you have a more detailed explanation wh=
y it could break?<br>

<p></p>

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

--e89a8fb20546c0932b04d86c75b6--

.

On Thu, Mar 21, 2013 at 10:04 AM, Oliver Kowalke
<oliver.kowalke@gmail.com> wrote:
> 2013/3/21 Giovanni Piero Deretta <gpderetta@gmail.com>
>>
>>    X::instance()->abc(); // may call the Y installed at this thread or
>> the previous one, depending on the phase of the moon.
>
>
> why should it break? X::instance() access the thread_local static class
> member 'y'. my understanding was that if I access 'y' I get the address
> stored by the current thread (in its TLS).
> if the code (not necessary a coroutine) is migrated to another thread 'y'
> returns another value.
> do you have a more detailed explanation why it could break?

I showed in a previous post. To make it short, the compiler, instead
of recomputing the address of X::y after the call to c(), can reuse
the previously computed value, as normally its address cannot change.
To be more likely to see the issue, you might need to change X::y from
a pointer to an actual instance of Y. But even the example as-is can
still break.

-- gpd

--

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



.

--f46d0447f2a81c627604d86cae6c
Content-Type: text/plain; charset=ISO-8859-1

2013/3/21 Giovanni Piero Deretta <gpderetta@gmail.com>

> I showed in a previous post. To make it short, the compiler, instead
> of recomputing the address of X::y after the call to c(), can reuse
> the previously computed value, as normally its address cannot change.
>

the standard does explicitly allow this optimization for thread_local
variables?

--

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



--f46d0447f2a81c627604d86cae6c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2013/3/21 Giovanni Piero Deretta <span dir=3D"lt=
r">&lt;<a href=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@g=
mail.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I showed in a previous post. To make it short, the compiler, instead<br>
of recomputing the address of X::y after the call to c(), can reuse<br>
the previously computed value, as normally its address cannot change.<br></=
blockquote></div><br>the standard does explicitly allow this optimization f=
or thread_local variables?<br>

<p></p>

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

--f46d0447f2a81c627604d86cae6c--

.

On Thu, Mar 21, 2013 at 10:19 AM, Oliver Kowalke
<oliver.kowalke@gmail.com> wrote:
> 2013/3/21 Giovanni Piero Deretta <gpderetta@gmail.com>
>>
>> I showed in a previous post. To make it short, the compiler, instead
>> of recomputing the address of X::y after the call to c(), can reuse
>> the previously computed value, as normally its address cannot change.
>
>
> the standard does explicitly allow this optimization for thread_local
> variables?
>

Implicitly, by the as-if rule. A conforming program can't tell as
normally a flow of execution cannot move to another thread. Arguably,
a compiler that claims POSIX compatibility shouldn't do this
optimization, though, as POSIX has (or had) swapcontext.

-- gpd

--

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



.

------=_Part_116_29140747.1363902832969
Content-Type: text/plain; charset=ISO-8859-1


On Friday, March 15, 2013 5:48:17 PM UTC, Oliver Kowalke wrote:
>
> Hi,
>
> this is the first version of the proposal to add coroutines to C++.
> The pdf can be found here: http://ok73.funpic.de/coroutine.pdf
>
> so long,
> Oliver
>

This is a bad proposal, do not do it like that!

--

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



------=_Part_116_29140747.1363902832969
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Friday, March 15, 2013 5:48:17 PM UTC, Oliver Kowalke wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">Hi,<br><br>this is the first version o=
f the proposal to add coroutines to C++.<br>The pdf can be found here: <a h=
ref=3D"http://ok73.funpic.de/coroutine.pdf" target=3D"_blank">http://ok73.f=
unpic.de/<wbr>coroutine.pdf</a><br><br>so long,<br>Oliver<br></blockquote><=
div><br></div><div>This is a bad proposal, do not do it like that!</div>

<p></p>

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

------=_Part_116_29140747.1363902832969--

.

--089e013a25863b35a904d8794ae1
Content-Type: text/plain; charset=ISO-8859-1

> This is a bad proposal, do not do it like that!
>
> You may want to consider throwing in a couple arguments ...

--

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



--089e013a25863b35a904d8794ae1
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>This is a bad proposal, do not do it like that!</div>
<div class="HOEnZb"><div class="h5">

<p></p></div></div></blockquote></div>You may want to consider throwing in a couple arguments ...</div></div>

<p></p>

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

--089e013a25863b35a904d8794ae1--

.

I would be better off writing a new proposal, which I fully intend to do.

Let me just say that I disagree with:

<Blockquote>This design decision makes the code using std::coroutine&lt;> let look more symmetric.</blockquote>

More symmetric does not make it more readable. Yuck. Do we really want to make C++11 more confusing?

--

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



.

I would be better off writing a new proposal, which I fully intend to do.
Let me just say that I disagree with:

[quote]This design decision makes the code using std::coroutine<> let look more symmetric.[/quote]

More symmetric does not make it more readable. Yuck. Do we really want to make C++11 more confusing?

--

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



.

--e89a8fb20346535c9a04d87fb058
Content-Type: text/plain; charset=ISO-8859-1

2013/3/22 <denisgoogle@bredelet.com>

> I would be better off writing a new proposal, which I fully intend to do.
> Let me just say that I disagree with:
>
> [quote]This design decision makes the code using std::coroutine<> let look
> more symmetric.[/quote]
>
> More symmetric does not make it more readable. Yuck. Do we really want to
> make C++11 more confusing?
>

I tried to express with the sentence you mention that you use a coroutine<>
to jump into the coro-function and you use a coroutine<> to jump out of it.

But there are some ideas that bidirectional coroutines should be split into
unidirectional ones (push_coroutine, pull coroutine), something like:

pull_coroutine< int > c(
        [&]( push_coroutine< int > & c) {
            int first = 1, second = 1;
            for ( int i = 0; i < 10; ++i)
            {
                int third = first + second;
                first = second;
                second = third;
                c( third);
            }
        });

for ( auto i : c)
  std::cout << i <<  " ";

and vice versa

(pull_coroutine has only a pull_coroutine::operator()() +
pull_coroutine::get(); push_coroutine has a push_coroutine::operator()( T)
and no get() )

--

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



--e89a8fb20346535c9a04d87fb058
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2013/3/22  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:denisgoogle@bredelet.com" target=3D"_blank">denisgoogle@bredelet.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 class=3D"im">I would be better off writing a new proposal, which I ful=
ly intend to do.<br>
Let me just say that I disagree with:<br>
<br>
</div>[quote]This design decision makes the code using std::coroutine&lt;&g=
t; let look more symmetric.[/quote]<br>
<div class=3D"im HOEnZb"><br>
More symmetric does not make it more readable. Yuck. Do we really want to m=
ake C++11 more confusing?<br></div></blockquote></div><br>I tried to expres=
s with the sentence you mention that you use a coroutine&lt;&gt; to jump in=
to the coro-function and you use a coroutine&lt;&gt; to jump out of it.<br>
<br>But there are some ideas that bidirectional coroutines should be split =
into unidirectional ones (push_coroutine, pull coroutine), something like:<=
br><br>pull_coroutine&lt; int &gt; c(<br>=A0=A0=A0=A0=A0=A0=A0 [&amp;]( pus=
h_coroutine&lt; int &gt; &amp; c) {<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 int first =3D 1, second =3D 1;<br>=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 for ( int i =3D 0; i &lt; 10; ++i)<br>=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 {<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 int third =3D first + second;<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 first =3D second;<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 s=
econd =3D third;<br>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 c( third);<br>=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 }<br>=A0=A0=A0=A0=A0=A0=A0 });<br><br>for ( auto i : c)<=
br>=A0 std::cout &lt;&lt; i &lt;&lt;=A0 &quot; &quot;;<br><br>and vice vers=
a<br><br>(pull_coroutine has only a pull_coroutine::operator()() + pull_cor=
outine::get(); push_coroutine has a push_coroutine::operator()( T) and no g=
et() )<br>
<div style id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

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

--e89a8fb20346535c9a04d87fb058--

.

------=_Part_499_26360550.1363943799591
Content-Type: text/plain; charset=ISO-8859-1

I'm currently working to support checkpointing of coroutines - I think it
would be useful too?!
Should I add it to the proposal?

--

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



------=_Part_499_26360550.1363943799591
Content-Type: text/html; charset=ISO-8859-1

I'm currently working to support checkpointing of coroutines - I think it would be useful too?!<br>Should I add it to the proposal?<br>

<p></p>

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

------=_Part_499_26360550.1363943799591--

.

On 3/22/13, denisgoogle@bredelet.com <denisgoogle@bredelet.com> wrote:
> I would be better off writing a new proposal, which I fully intend to do.

Having it available before the April meeting would be most helpful.

--
Lawrence Crowl

--

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



.

On 3/22/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> I'm currently working to support checkpointing of coroutines -
> I think it would be useful too?!  Should I add it to the proposal?

Useful for what purposes?  As a component in checkpointing an
entire process?  What other tools are needed to make that happen?

--
Lawrence Crowl

--

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



.

--e89a8fb2055a61b63f04d888b0ec
Content-Type: text/plain; charset=ISO-8859-1

2013/3/22 Lawrence Crowl <crowl@googlers.com>

> On 3/22/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> > I'm currently working to support checkpointing of coroutines -
> > I think it would be useful too?!  Should I add it to the proposal?
>
> Useful for what purposes?  As a component in checkpointing an
> entire process?  What other tools are needed to make that happen?
>

I mean checkpointing a coroutine, also known as multi-shot coroutine.
Something like this:

checkpoint cp;
std::coroutine< int() > c(
   [&](std::coroutine< void( int) > & c) {
      int i = 0;
      cp = c.checkpoint(); // coroutine checkpoint
      std::cout << "ABC" << std::endl;
      while ( true) {
         c( ++i);
});

for ( int x = 0; x<3; ++x) {
   std::cout << c().get() << std::endl;

c.rollback( cp);

for ( int x = 0; x<5; ++x) {
   std::cout << c().get() << std::endl;

output should be:
1
2
3
ABC
1
2
3
4
5

--

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



--e89a8fb2055a61b63f04d888b0ec
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote">2013/3/22 Lawrence Crowl <span dir=3D"ltr">&=
lt;<a href=3D"mailto:crowl@googlers.com" target=3D"_blank">crowl@googlers.c=
om</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 class=3D"im">On 3/22/13, Oliver Kowalke &lt;<a href=3D"mailto:oliver.k=
owalke@gmail.com">oliver.kowalke@gmail.com</a>&gt; wrote:<br>
&gt; I&#39;m currently working to support checkpointing of coroutines -<br>
&gt; I think it would be useful too?! =A0Should I add it to the proposal?<b=
r>
<br>
</div>Useful for what purposes? =A0As a component in checkpointing an<br>
entire process? =A0What other tools are needed to make that happen?<br></bl=
ockquote></div><br>I mean checkpointing a coroutine, also known as multi-sh=
ot coroutine.<br>Something like this:<br><br>checkpoint cp;<br>std::corouti=
ne&lt; int() &gt; c(<br>
=A0=A0 [&amp;](std::coroutine&lt; void( int) &gt; &amp; c) {<br>=A0=A0=A0=
=A0=A0 int i =3D 0;<br>=A0=A0=A0=A0=A0 cp =3D c.checkpoint(); // coroutine =
checkpoint<br>=A0=A0=A0=A0=A0 std::cout &lt;&lt; &quot;ABC&quot; &lt;&lt; s=
td::endl;<br>=A0=A0=A0=A0=A0 while ( true) {<br>
=A0=A0=A0=A0=A0=A0=A0=A0 c( ++i);<br>});<br><br>for ( int x =3D 0; x&lt;3; =
++x) {<br>=A0=A0 std::cout &lt;&lt; c().get() &lt;&lt; std::endl;<br><br>c.=
rollback( cp);<br><br>for ( int x =3D 0; x&lt;5; ++x) {<br>=A0=A0 std::cout=
 &lt;&lt; c().get() &lt;&lt; std::endl;<br>
<br>output should be:<br>1<br>2<br>3<br>ABC<br>1<br>2<br>3<br>4<br>5<br><di=
v style id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

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

--e89a8fb2055a61b63f04d888b0ec--

.

On 3/22/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> 2013/3/22 Lawrence Crowl <crowl@googlers.com>
> > On 3/22/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> > > I'm currently working to support checkpointing of coroutines -
> > > I think it would be useful too?!  Should I add it to the proposal?
> >
> > Useful for what purposes?  As a component in checkpointing an
> > entire process?  What other tools are needed to make that happen?
>
> I mean checkpointing a coroutine, also known as multi-shot coroutine.
> Something like this:
>
> checkpoint cp;
> std::coroutine< int() > c(
>    [&](std::coroutine< void( int) > & c) {
>       int i = 0;
>       cp = c.checkpoint(); // coroutine checkpoint
>       std::cout << "ABC" << std::endl;
>       while ( true) {
>          c( ++i);
> });
>
> for ( int x = 0; x<3; ++x) {
>    std::cout << c().get() << std::endl;
>
> c.rollback( cp);
>
> for ( int x = 0; x<5; ++x) {
>    std::cout << c().get() << std::endl;
>
> output should be:
> 1
> 2
> 3
> ABC
> 1
> 2
> 3
> 4
> 5

What is the use case for which this facility would be useful?

Well motivated proposals have a much easier time making it through
the process.

--
Lawrence Crowl

--

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



.

------=_Part_311_29128828.1364051991054
Content-Type: text/plain; charset=ISO-8859-1

Hi Oliver,

On Friday, March 22, 2013 9:00:37 AM UTC, Oliver Kowalke wrote:
>
> 2013/3/22 <denis...@bredelet.com <javascript:>>
>
>> I would be better off writing a new proposal, which I fully intend to do.
>> Let me just say that I disagree with:
>>
>> [quote]This design decision makes the code using std::coroutine<> let
>> look more symmetric.[/quote]
>>
>> More symmetric does not make it more readable. Yuck. Do we really want to
>> make C++11 more confusing?
>>
>
> I tried to express with the sentence you mention that you use a
> coroutine<> to jump into the coro-function and you use a coroutine<> to
> jump out of it.
>
> But there are some ideas that bidirectional coroutines should be split
> into unidirectional ones (push_coroutine, pull coroutine), something like:
>
> pull_coroutine< int > c(
>         [&]( push_coroutine< int > & c) {
>             int first = 1, second = 1;
>             for ( int i = 0; i < 10; ++i)
>             {
>                 int third = first + second;
>                 first = second;
>                 second = third;
>                 c( third);
>             }
>         });
>
> for ( auto i : c)
>   std::cout << i <<  " ";
>
> and vice versa
>
> (pull_coroutine has only a pull_coroutine::operator()() +
> pull_coroutine::get(); push_coroutine has a push_coroutine::operator()( T)
> and no get() )
>

Right, that looks much better. Do you want to add it as an alternative in
your proposal?

--

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



------=_Part_311_29128828.1364051991054
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Oliver,<br><br>On Friday, March 22, 2013 9:00:37 AM UTC, Oliver Kowalke =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quot=
e">2013/3/22  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"JZujqk7wfjEJ">denis...@bredelet.com</a>&gt;</sp=
an><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div>I would be better off writing a new proposal, which I fully intend to =
do.<br>
Let me just say that I disagree with:<br>
<br>
</div>[quote]This design decision makes the code using std::coroutine&lt;&g=
t; let look more symmetric.[/quote]<br>
<div><br>
More symmetric does not make it more readable. Yuck. Do we really want to m=
ake C++11 more confusing?<br></div></blockquote></div><br>I tried to expres=
s with the sentence you mention that you use a coroutine&lt;&gt; to jump in=
to the coro-function and you use a coroutine&lt;&gt; to jump out of it.<br>
<br>But there are some ideas that bidirectional coroutines should be split =
into unidirectional ones (push_coroutine, pull coroutine), something like:<=
br><br>pull_coroutine&lt; int &gt; c(<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; [&amp;]( push_coroutine&lt; int &gt; &amp; c) {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int firs=
t =3D 1, second =3D 1;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp; for ( int i =3D 0; i &lt; 10; ++i)<br>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {<br>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int th=
ird =3D first + second;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; first =3D second;<br>&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; second =3D third;<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp; c( third);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; });<b=
r><br>for ( auto i : c)<br>&nbsp; std::cout &lt;&lt; i &lt;&lt;&nbsp; " ";<=
br><br>and vice versa<br><br>(pull_coroutine has only a pull_coroutine::ope=
rator()() + pull_coroutine::get(); push_coroutine has a push_coroutine::ope=
rator()( T) and no get() )<br></blockquote><div><br></div><div>Right, that =
looks much better. Do you want to add it as an alternative in your proposal=
?&nbsp;</div>

<p></p>

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

------=_Part_311_29128828.1364051991054--

.

--e89a8fb20546a78e6204d89a3631
Content-Type: text/plain; charset=ISO-8859-1

2013/3/23 Lawrence Crowl <crowl@googlers.com>

> What is the use case for which this facility would be useful?
>
> Well motivated proposals have a much easier time making it through
> the process.
>

checkpointing could be used:

- speculativ execution: for instance optimistic algorithms for simulations
can be rolled back to a checkpoint if desired
  -> I got some requestes from game-develoeprs to provide it in
boost.coroutine (I guess it would be used for state-machines)

- copy of coroutine:
copying a statefull coroutine is not possible if you think on copying the
associated stack. the copy-operation would require to copy the
control-block (stack-pointer,
instruction pointer, some CPU registers) and content of stack. If your code
uses the address of stack-local variables you get undefined behaviour in
the
target-coroutine. That is because the address points to an object on
another stack, not on the stack associated with the target coroutine.
Therefore I wrote that coroutine should be move-only.
I think with checkpointing you can provide something like 'copying' a
coroutine. If you require that coroutines can act only concurrent but not
in parallel (== a copies of
a coroutine must not run in different threads) we could use checkpoints to
load and store the stack-content + control-block for a coroutine and mimic
something like
copies of a coroutine. But this needs some thoughts (for isntance
resource-managment with RAII etc. might be provide some pitfalls).
  -> to copy a coroutine was also requested by game-developers

--

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



--e89a8fb20546a78e6204d89a3631
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2013/3/23 Lawrence Crowl <span dir=3D"ltr">&lt;<=
a href=3D"mailto:crowl@googlers.com" target=3D"_blank">crowl@googlers.com</=
a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">

What is the use case for which this facility would be useful?<br>
<br>
Well motivated proposals have a much easier time making it through<br>
the process.<br></blockquote></div><br>checkpointing could be used:<br><br>=
- speculativ execution: for instance optimistic algorithms for simulations =
can be rolled back to a checkpoint if desired<br>=A0 -&gt; I got some reque=
stes from game-develoeprs to provide it in boost.coroutine (I guess it woul=
d be used for state-machines)<br>

<br>- copy of coroutine:<br>copying a statefull coroutine is not possible i=
f you think on copying the associated stack. the copy-operation would requi=
re to copy the control-block (stack-pointer,<br>instruction pointer, some C=
PU registers) and content of stack. If your code uses the address of stack-=
local variables you get undefined behaviour in the <br>
target-coroutine. That is because the address points to an object on anothe=
r stack, not on the stack associated with the target coroutine.<br>Therefor=
e I wrote that coroutine should be move-only.<br>I think with checkpointing=
 you can provide something like &#39;copying&#39; a coroutine. If you requi=
re that coroutines can act only concurrent but not in parallel (=3D=3D a co=
pies of<br>
a coroutine must not run in different threads) we could use checkpoints to =
load and store the stack-content + control-block for a coroutine and mimic =
something like<br>copies of a coroutine. But this needs some thoughts (for =
isntance resource-managment with RAII etc. might be provide some pitfalls).=
<br>
=A0 -&gt; to copy a coroutine was also requested by game-developers<br>
<div></div>
<div style id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

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

--e89a8fb20546a78e6204d89a3631--

.

--e89a8fb2054687832204d89a7820
Content-Type: text/plain; charset=ISO-8859-1

2013/3/23 <denisgoogle@bredelet.com>
>
> Right, that looks much better. Do you want to add it as an alternative in
> your proposal?
>

Of course if it's the outcome of this thread.

I believe that C++ needs something like coroutines - at least I know that
some C++-applications use coroutines (for instance 'Simple Life').
My intention for this proposal was to get a discuss in this forum how C++
coroutines should look like.
I choose boost.coroutine as starting-point because it is working C++-code
and was already reviewed by the boost-community.
But this does not mean that the proposal is immutable - I still hope to get
some ideas from other C++-user to improve the proposal (Giovanni already
suggested the unidirectional coroutines).
For instance I think we need some ideas about checkpointing/copying
coroutiens or what about delimited continuations/sub-coroutines etc.

--

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



--e89a8fb2054687832204d89a7820
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2013/3/23  <span dir=3D"ltr">&lt;<a href=3D"mail=
to:denisgoogle@bredelet.com" target=3D"_blank">denisgoogle@bredelet.com</a>=
&gt;</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">
<div></div><div>Right, that looks much better. Do you want to add it as an =
alternative in your proposal?<br></div></blockquote><div><br>Of course if i=
t&#39;s the outcome of this thread.<br><br>I believe that C++ needs somethi=
ng like coroutines - at least I know that some C++-applications use corouti=
nes (for instance &#39;Simple Life&#39;).<br>
My intention for this proposal was to get a discuss in this forum how C++ c=
oroutines should look like.<br>I choose boost.coroutine as starting-point b=
ecause it is working C++-code and was already reviewed by the boost-communi=
ty.<br>
But this does not mean that the proposal is immutable - I still hope to get=
 some ideas from other C++-user to improve the proposal (Giovanni already s=
uggested the unidirectional coroutines).<br>For instance I think we need so=
me ideas about checkpointing/copying coroutiens or what about delimited con=
tinuations/sub-coroutines etc.<br>
</div></div><div style id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></=
div>

<p></p>

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

--e89a8fb2054687832204d89a7820--

.

On 23 March 2013 18:57, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> 2013/3/23 <denisgoogle@bredelet.com>
>> Right, that looks much better. Do you want to add it as an alternative in
>> your proposal?
> Of course if it's the outcome of this thread.

I recommend being careful about forming a proposal based on the feedback on
this forum. You will get the opinion of just anyone, whether sane 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Sat, Mar 23, 2013 at 5:39 PM, Oliver Kowalke
<oliver.kowalke@gmail.com> wrote:
> 2013/3/23 Lawrence Crowl <crowl@googlers.com>
>>
>> What is the use case for which this facility would be useful?
>>
>> Well motivated proposals have a much easier time making it through
>> the process.
>
>
> checkpointing could be used:
>
> - speculativ execution: for instance optimistic algorithms for simulations
> can be rolled back to a checkpoint if desired

An example of this is the Amb special form in scheme (implemented on
top of continuations) used for backtracking
http://c2.com/cgi/wiki?AmbSpecialForm .

Checkpointable coroutines are, in general, as powerful as full continuations.

-- gpd

--

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



.

On Sat, Mar 23, 2013 at 1:09 AM, Lawrence Crowl <crowl@googlers.com> wrote:
> On 3/22/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
>> 2013/3/22 Lawrence Crowl <crowl@googlers.com>
>> > On 3/22/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
>> > > I'm currently working to support checkpointing of coroutines -
>> > > I think it would be useful too?!  Should I add it to the proposal?
>> >
>> > Useful for what purposes?  As a component in checkpointing an
>> > entire process?  What other tools are needed to make that happen?
>>
>> I mean checkpointing a coroutine, also known as multi-shot coroutine.
>> Something like this:
>> [snip]
>
> What is the use case for which this facility would be useful?
>
> Well motivated proposals have a much easier time making it through
> the process.
>

A classic use case for multi-shot coroutines/continuations is for
handling the  back button in web applications. At every page the
server checkpoint/caputure the state of the user interaction in a
continuation, and when the user cliks the back button it replays a
previous continuation.

-- gpd

--

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



.

--089e0149d0b22bf80104d8a7bcdc
Content-Type: text/plain; charset=ISO-8859-1

2013/3/23 <denisgoogle@bredelet.com>
>
> Right, that looks much better. Do you want to add it as an alternative in
> your proposal?
>

added as alternative design to proposal

best regards,
Oliver

--

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



--089e0149d0b22bf80104d8a7bcdc
Content-Type: text/html; charset=ISO-8859-1

<div class="gmail_quote">2013/3/23  <span dir="ltr">&lt;<a href="mailto:denisgoogle@bredelet.com" target="_blank">denisgoogle@bredelet.com</a>&gt;</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div><div>Right, that looks much better. Do you want to add it as an alternative in your proposal?</div></blockquote><div><br>added as alternative design to proposal<br><br>best regards,<br>Oliver <br></div></div><br>
<div style id="__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

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

--089e0149d0b22bf80104d8a7bcdc--

.

------=_Part_222_16975079.1364131564540
Content-Type: text/plain; charset=ISO-8859-1

Isn't await (N3564) going to deliver mostly the same functionality (but
putting the "local" variables into a compiler-generated object).

Michael

On Friday, March 15, 2013 6:48:17 PM UTC+1, Oliver Kowalke wrote:
>
> Hi,
>
> this is the first version of the proposal to add coroutines to C++.
> The pdf can be found here: http://ok73.funpic.de/coroutine.pdf
>
> so long,
> Oliver
>

--

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



------=_Part_222_16975079.1364131564540
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Isn't await (N3564) going to deliver mostly the same functionality (but put=
ting the "local" variables into a compiler-generated object).<div><br></div=
><div>Michael<br><br>On Friday, March 15, 2013 6:48:17 PM UTC+1, Oliver Kow=
alke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,<br><br>this is =
the first version of the proposal to add coroutines to C++.<br>The pdf can =
be found here: <a href=3D"http://ok73.funpic.de/coroutine.pdf" target=3D"_b=
lank">http://ok73.funpic.de/<wbr>coroutine.pdf</a><br><br>so long,<br>Olive=
r<br><div></div></blockquote></div>

<p></p>

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

------=_Part_222_16975079.1364131564540--

.

--e89a8fb2033457d98704d8ac39d4
Content-Type: text/plain; charset=ISO-8859-1

2013/3/24 Michael Bruck <bruck.michael@gmail.com>

> Isn't await (N3564) going to deliver mostly the same functionality (but
> putting the "local" variables into a compiler-generated object).
>

after a brief look at N3564 it seams not to be the same because I believe
it does not provide some kind of escape-and-reenter of loops or
recursive computations. After reading the code snippets I think you can't
solve the same fringe problem with 'await' as done with coroutines.
As N3564 describes 'After suspending, a resumable function may be resumed
by the scheduling logic of the runtime...' - seams not to be
equivalent cooperative scheduling.

--

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



--e89a8fb2033457d98704d8ac39d4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2013/3/24 Michael Bruck <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:bruck.michael@gmail.com" target=3D"_blank">bruck.michael@gm=
ail.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">
Isn&#39;t await (N3564) going to deliver mostly the same functionality (but=
 putting the &quot;local&quot; variables into a compiler-generated object).=
<br></blockquote></div><br>after a brief look at N3564 it seams not to be t=
he same because I believe it does not provide some kind of escape-and-reent=
er of loops or<br>
recursive computations. After reading the code snippets I think you can&#39=
;t solve the same fringe problem with &#39;await&#39; as done with coroutin=
es.<br>As N3564 describes &#39;After suspending, a resumable function may b=
e resumed by the scheduling logic of the runtime...&#39; - seams not to be<=
br>
equivalent cooperative scheduling.<br><div style id=3D"__af745f8f43-e961-4b=
88-8424-80b67790c964__"></div>

<p></p>

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

--e89a8fb2033457d98704d8ac39d4--

.

On 3/23/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> 2013/3/23 Lawrence Crowl <crowl@googlers.com>
>
>> What is the use case for which this facility would be useful?
>>
>> Well motivated proposals have a much easier time making it through
>> the process.
>>
>
> checkpointing could be used:
>
> - speculativ execution: for instance optimistic algorithms for simulations
> can be rolled back to a checkpoint if desired
>   -> I got some requestes from game-develoeprs to provide it in
> boost.coroutine (I guess it would be used for state-machines)
>
> - copy of coroutine:
> copying a statefull coroutine is not possible if you think on copying the
> associated stack. the copy-operation would require to copy the
> control-block (stack-pointer,
> instruction pointer, some CPU registers) and content of stack. If your code
> uses the address of stack-local variables you get undefined behaviour in
> the
> target-coroutine. That is because the address points to an object on
> another stack, not on the stack associated with the target coroutine.
> Therefore I wrote that coroutine should be move-only.
> I think with checkpointing you can provide something like 'copying' a
> coroutine. If you require that coroutines can act only concurrent but not
> in parallel (== a copies of
> a coroutine must not run in different threads) we could use checkpoints to
> load and store the stack-content + control-block for a coroutine and mimic
> something like
> copies of a coroutine. But this needs some thoughts (for isntance
> resource-managment with RAII etc. might be provide some pitfalls).
>   -> to copy a coroutine was also requested by game-developers

I would like to see this discussion in a revision of the paper.

--
Lawrence Crowl

--

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



.

On 3/24/13, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
> 2013/3/24 Michael Bruck <bruck.michael@gmail.com>
> > Isn't await (N3564) going to deliver mostly the same
> > functionality (but putting the "local" variables into a
> > compiler-generated object).
>
> after a brief look at N3564 it seams not to be the same because
> I believe it does not provide some kind of escape-and-reenter of
> loops or recursive computations. After reading the code snippets
> I think you can't solve the same fringe problem with 'await'
> as done with coroutines.  As N3564 describes 'After suspending,
> a resumable function may be resumed by the scheduling logic of the
> runtime...' - seams not to be equivalent cooperative scheduling.

We do need to be careful to identify common parts of proposals.
I view the task of the committee as finding a fusion/sythesis of
the various proposals so that we deliver maximum functionality for
minimum complexity.

So, I make a plea to all paper reviewers to look at how the proposals
interact, and how they might be merged into cleaner functionality.

--
Lawrence Crowl

--

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



.

--089e0139fc04c70aa804d8b6854a
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <oliver.kowalke@gmail.com>wrote:

> it does not provide some kind of escape-and-reenter of loops


If I understand this correctly you mean something like this:

std :: coroutine <int() > c (
  [&]( std :: coroutine <void(int) > & c ){

    for (int i = 0; i < 10; ++i)
       c(i);
});

int ret = 0;
for (; c ; c ())
  ret += c . get ();

With await you should be able to write a helper class multi_return<T> such
that:

future<void> corot(multi_return<int> & mr) resumable
{
    for (int i = 0; i < 10; ++i)
       await mr.set(i);

    mr.terminate();
}

multi_return<int> mr;

corot(mr);

int ret = 0;
while (mr.running())
  ret += mr.get();


The set() and get() methods on multi_return<T> can control each other via
some gadgets from the #include <future>. The key here is that due to await
compiler magic corot() returns as soon as it encounters a blocking await
and is afterwards restarted at the await once the blocking ended. To
implement the multi-return functionality you use the await to pause the
function once you found the first return value and resume it once this was
consumed via the get() method.


Michael

--

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



--089e0139fc04c70aa804d8b6854a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">oliver.kowalke@gma=
il.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"> it does not provide some kind of escape-and-reenter of lo=
ops</blockquote>
</div><div class=3D"gmail_extra"><br></div>If I understand this correctly y=
ou mean something like this:</div><div class=3D"gmail_extra"><div class=3D"=
gmail_extra"><br></div><div class=3D"gmail_extra">std :: coroutine &lt;int(=
) &gt; c (</div>
<div class=3D"gmail_extra">=A0 [&amp;]( std :: coroutine &lt;void(int) &gt;=
 &amp; c ){</div><div class=3D"gmail_extra" style><br></div><div class=3D"g=
mail_extra" style>=A0 =A0 for (int i =3D 0; i &lt; 10; ++i)</div><div class=
=3D"gmail_extra" style>
=A0 =A0 =A0 =A0c(i);</div><div class=3D"gmail_extra">});<br></div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>int ret =3D 0;=
</div><div class=3D"gmail_extra">for (; c ; c ())</div><div class=3D"gmail_=
extra">=A0 ret +=3D c . get ();</div>
<br></div><div class=3D"gmail_extra" style>With await you should be able to=
 write a helper class multi_return&lt;T&gt; such that:</div><div class=3D"g=
mail_extra" style><br></div><div class=3D"gmail_extra" style>future&lt;void=
&gt; corot(multi_return&lt;int&gt; &amp; mr) resumable<br>
</div><div class=3D"gmail_extra" style>{</div><div class=3D"gmail_extra">=
=A0 =A0 for (int i =3D 0; i &lt; 10; ++i)</div><div class=3D"gmail_extra">=
=A0 =A0 =A0 =A0await mr.set(i);</div><div class=3D"gmail_extra" style><br><=
/div><div class=3D"gmail_extra" style>
=A0 =A0 mr.terminate();</div><div class=3D"gmail_extra" style>}</div><div c=
lass=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style>multi=
_return&lt;int&gt; mr;<br></div><div class=3D"gmail_extra" style><br></div>=
<div class=3D"gmail_extra" style>
corot(mr);</div><div class=3D"gmail_extra" style><br></div><div class=3D"gm=
ail_extra" style><div class=3D"gmail_extra">int ret =3D 0;</div><div class=
=3D"gmail_extra">while (mr.running())</div><div class=3D"gmail_extra">=A0 r=
et +=3D mr.get();</div>
<div><br></div></div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra" style>The set() and get() methods on multi_return&lt;T&gt; can co=
ntrol each other via some gadgets from the #include &lt;future&gt;. The key=
 here is that due to await compiler magic corot() returns as soon as it enc=
ounters a blocking await and is afterwards restarted at the await once the =
blocking ended. To implement the multi-return functionality you use the awa=
it to pause the function once you found the first return value and resume i=
t once this was consumed via the get() method.</div>
<div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
><br></div><div class=3D"gmail_extra" style>Michael</div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra">
<br></div></div>

<p></p>

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

--089e0139fc04c70aa804d8b6854a--

.

--e89a8f83a34b021c9904d8b8deed
Content-Type: text/plain; charset=ISO-8859-1

No. Oliver's point seems to be something similar to differences between
generator and coroutine. See below psuedo codes:

# if python supports coroutine...
def iterate_tree(coro, node):
  if node:
    iterate_tree(coro, node.left)
    coro(node.value)
    iterate_tree(coro, node.right)

# with current python generator
def iterate_tree(node):
  if node:
    for child in iterate_tree(node.left): # implicitly creates generator
object
      yield child
    yield node.value
    for child in iterate_tree(node.right): # also creates
      yield child

It's fairly tedious job to efficiently implement something like above code
with generator.

Adapting N3564 to this problem makes it even worse - you need to make
future object for every items - though the purpose of proposal is support
asynchronous job rather than enhancing control flow.

I think most parts of N3564 can be covered by solution built on
coroutine(or context switching primitive), without introducing additional
language complexity.


On Mon, Mar 25, 2013 at 11:25 AM, Michael Bruck <bruck.michael@gmail.com>wrote:

>
> On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <oliver.kowalke@gmail.com>wrote:
>
>> it does not provide some kind of escape-and-reenter of loops
>
>
> If I understand this correctly you mean something like this:
>
> std :: coroutine <int() > c (
>   [&]( std :: coroutine <void(int) > & c ){
>
>     for (int i = 0; i < 10; ++i)
>        c(i);
> });
>
> int ret = 0;
> for (; c ; c ())
>   ret += c . get ();
>
> With await you should be able to write a helper class multi_return<T> such
> that:
>
> future<void> corot(multi_return<int> & mr) resumable
> {
>     for (int i = 0; i < 10; ++i)
>        await mr.set(i);
>
>     mr.terminate();
> }
>
> multi_return<int> mr;
>
> corot(mr);
>
> int ret = 0;
> while (mr.running())
>   ret += mr.get();
>
>
> The set() and get() methods on multi_return<T> can control each other via
> some gadgets from the #include <future>. The key here is that due to await
> compiler magic corot() returns as soon as it encounters a blocking await
> and is afterwards restarted at the await once the blocking ended. To
> implement the multi-return functionality you use the await to pause the
> function once you found the first return value and resume it once this was
> consumed via the get() method.
>
>
> Michael
>
>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>



--
Min-chul Park (summerlight00@gmail.com / http://summerlight.tistory.com)

--

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



--e89a8f83a34b021c9904d8b8deed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">No. Oliver&#39;s point seems to be something similar to di=
fferences between generator and coroutine. See below psuedo codes:<div><br>=
</div><div style># if python supports coroutine...</div><div>def iterate_tr=
ee(coro, node):<br>
<div style>=A0 if node:</div><div style>=A0 =A0 iterate_tree(coro, node.lef=
t)</div></div><div style>=A0 =A0 coro(node.value)</div><div style>=A0 =A0 i=
terate_tree(coro, node.right)</div><div style><br></div><div style># with c=
urrent python generator</div>
<div style>def iterate_tree(node):</div><div style>=A0 if node:</div><div s=
tyle>=A0 =A0 for child in iterate_tree(node.left): # implicitly creates gen=
erator object</div><div style>=A0 =A0 =A0 yield child</div><div style>=A0 =
=A0 yield node.value</div>
<div style>=A0 =A0 for child in iterate_tree(node.right): # also creates</d=
iv><div>=A0 =A0 =A0 yield child</div><div style><br></div><div style>It&#39=
;s fairly tedious job to efficiently implement something like above code wi=
th generator.</div>
<div style><br></div><div style>Adapting N3564 to this problem makes it eve=
n worse - you need to make future object for every items - though the purpo=
se of proposal is support asynchronous job rather than enhancing control fl=
ow.</div>
<div style><br></div><div style>I think most parts of N3564 can be covered =
by solution built on coroutine(or context switching primitive), without int=
roducing additional language complexity.</div></div><div class=3D"gmail_ext=
ra">
<br><br><div class=3D"gmail_quote">On Mon, Mar 25, 2013 at 11:25 AM, Michae=
l Bruck <span dir=3D"ltr">&lt;<a href=3D"mailto:bruck.michael@gmail.com" ta=
rget=3D"_blank">bruck.michael@gmail.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"im"><br><div clas=
s=3D"gmail_quote">On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <span dir=
=3D"ltr">&lt;<a href=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">=
oliver.kowalke@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"> it does not provide some kind of escape-and-reenter of lo=
ops</blockquote>

</div><div class=3D"gmail_extra"><br></div></div>If I understand this corre=
ctly you mean something like this:</div><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">std :: coroutine &l=
t;int() &gt; c (</div>
<div class=3D"im">
<div class=3D"gmail_extra">=A0 [&amp;]( std :: coroutine &lt;void(int) &gt;=
 &amp; c ){</div><div class=3D"gmail_extra"><br></div></div><div class=3D"g=
mail_extra">=A0 =A0 for (int i =3D 0; i &lt; 10; ++i)</div><div class=3D"gm=
ail_extra">

=A0 =A0 =A0 =A0c(i);</div><div class=3D"gmail_extra">});<br></div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">int ret =3D 0;</div>=
<div class=3D"gmail_extra">for (; c ; c ())</div><div class=3D"gmail_extra"=
>=A0 ret +=3D c . get ();</div>

<br></div><div class=3D"gmail_extra">With await you should be able to write=
 a helper class multi_return&lt;T&gt; such that:</div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">future&lt;void&gt; corot(multi_r=
eturn&lt;int&gt; &amp; mr) resumable<br>

</div><div class=3D"gmail_extra">{</div><div class=3D"gmail_extra">=A0 =A0 =
for (int i =3D 0; i &lt; 10; ++i)</div><div class=3D"gmail_extra">=A0 =A0 =
=A0 =A0await mr.set(i);</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">
=A0 =A0 mr.terminate();</div><div class=3D"gmail_extra">}</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">multi_return&lt;int&g=
t; mr;<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">
corot(mr);</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra"><div class=3D"gmail_extra">int ret =3D 0;</div><div class=3D"gmail_ext=
ra">while (mr.running())</div><div class=3D"gmail_extra">=A0 ret +=3D mr.ge=
t();</div>
<div><br></div></div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">The set() and get() methods on multi_return&lt;T&gt; can control =
each other via some gadgets from the #include &lt;future&gt;. The key here =
is that due to await compiler magic corot() returns as soon as it encounter=
s a blocking await and is afterwards restarted at the await once the blocki=
ng ended. To implement the multi-return functionality you use the await to =
pause the function once you found the first return value and resume it once=
 this was consumed via the get() method.</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">Michael</div><div class=3D"gmail_extra"><br></div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">
<br></div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div>Min-chul Park (<a href=3D"mailto:summerlight00@gmail.com" target=3D"_b=
lank">summerlight00@gmail.com</a>=A0/ <a href=3D"http://summerlight.tistory=
..com/" target=3D"_blank">http://summerlight.tistory.com</a>)</div>

</div>

<p></p>

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

--e89a8f83a34b021c9904d8b8deed--

.

------=_Part_3040_8987466.1364194937471
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, March 24, 2013 8:47:14 AM UTC, Oliver Kowalke wrote:
>
> 2013/3/23 <denis...@bredelet.com <javascript:>>
>>
>> Right, that looks much better. Do you want to add it as an alternative in
>> your proposal?
>>
>
> added as alternative design to proposal
>
> Nice.

My concern with:

std::pull_coroutine <int> c( [&](std::push_coroutine <int> & c) {


is that the type of the push_coroutine is not indicated in the
pull_coroutine, shouldn't it be std::pull_coroutine <int(int)>?

--

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



------=_Part_3040_8987466.1364194937471
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, March 24, 2013 8:47:14 AM UTC, Oliver Kowalke wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote">2013/3/=
23  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"ljm6boKSAdIJ">denis...@bredelet.com</a>&gt;</span><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div></div><div>Right, that looks much better. Do you want to add it as an =
alternative in your proposal?</div></blockquote><div><br>added as alternati=
ve design to proposal<br><br></div></div></blockquote><div>Nice.</div><div>=
<br></div><div>My concern with:</div>
 =09
=09
=09
  <blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><di=
v><span style=3D"font-size: 9pt; font-family: CMTT9; ">std::pull_coroutine =
&lt;</span><span style=3D"font-size: 9pt; font-family: CMTT9; color: rgb(0,=
 0, 255); ">int</span><span style=3D"font-size: 9pt; font-family: CMTT9; ">=
&gt; c(
[&amp;](std::push_coroutine &lt;</span><span style=3D"font-size: 9pt; font-=
family: CMTT9; color: rgb(0, 0, 255); ">int</span><span style=3D"font-size:=
 9pt; font-family: CMTT9; ">&gt; &amp; c) {</span>&nbsp;</div></blockquote>=
<div><br></div><div>is that the type of the push_coroutine is not indicated=
 in the pull_coroutine, shouldn't it be std::pull_coroutine &lt;int(int)&gt=
;?</div>

<p></p>

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

------=_Part_3040_8987466.1364194937471--

.

------=_Part_885_4568952.1364195198091
Content-Type: text/plain; charset=ISO-8859-1



On Sunday, March 24, 2013 8:47:14 AM UTC, Oliver Kowalke wrote:
>
> 2013/3/23 <denis...@bredelet.com <javascript:>>
>>
>> Right, that looks much better. Do you want to add it as an alternative in
>> your proposal?
>>
>
> added as alternative design to proposal
>

Nice.

>

--

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



------=_Part_885_4568952.1364195198091
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>On Sunday, March 24, 2013 8:47:14 AM UTC, Oliver Kowalke wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote">2013/3/=
23  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"ljm6boKSAdIJ">denis...@bredelet.com</a>&gt;</span><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div></div><div>Right, that looks much better. Do you want to add it as an =
alternative in your proposal?</div></blockquote><div><br>added as alternati=
ve design to proposal<br></div></div></blockquote><div><br></div><div>Nice.=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div></div>
</blockquote>

<p></p>

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

------=_Part_885_4568952.1364195198091--

.

--e89a8fb1f7a64bfe0504d8ba9883
Content-Type: text/plain; charset=ISO-8859-1

2013/3/25 Denis Bredelet <denisgoogle@bredelet.com>
>
> My concern with:
>
> std::pull_coroutine <int> c( [&](std::push_coroutine <int> & c) {
>
>
> is that the type of the push_coroutine is not indicated in the
> pull_coroutine, shouldn't it be std::pull_coroutine <int(int)>?
>

push_coroutine and pull_coroutine take the type transferred via the context
switch as template arguments not the Signature.

pull_coroutine< int > == you get an int from the other context (you pull it
from)
- int pull_coroutine<int>::get()
- pull_coroutine<int>::operator()() // no int as argument!

push_coroutine< int > == you transfer an int to the other context (you push
it to)
- push_coroutine<int>::operator()( int)
// no push_coroutine::get() !

pull_coroutine and push_coroutine occur always as pair

--

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



--e89a8fb1f7a64bfe0504d8ba9883
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2013/3/25 Denis Bredelet <span dir=3D"ltr">&lt;<=
a href=3D"mailto:denisgoogle@bredelet.com" target=3D"_blank">denisgoogle@br=
edelet.com</a>&gt;</span><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>My concern with:</div>
 =09
=09
=09
  <blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><spa=
n style=3D"font-size:9pt;font-family:CMTT9">std::pull_coroutine &lt;</span>=
<span style=3D"font-size:9pt;font-family:CMTT9;color:rgb(0,0,255)">int</spa=
n><span style=3D"font-size:9pt;font-family:CMTT9">&gt; c(
[&amp;](std::push_coroutine &lt;</span><span style=3D"font-size:9pt;font-fa=
mily:CMTT9;color:rgb(0,0,255)">int</span><span style=3D"font-size:9pt;font-=
family:CMTT9">&gt; &amp; c) {</span>=A0</div></blockquote><div><br></div><d=
iv>
is that the type of the push_coroutine is not indicated in the pull_corouti=
ne, shouldn&#39;t it be std::pull_coroutine &lt;int(int)&gt;?<br></div></bl=
ockquote></div><br>push_coroutine and pull_coroutine take the type transfer=
red via the context switch as template arguments not the Signature.<br>
<br>pull_coroutine&lt; int &gt; =3D=3D you get an int from the other contex=
t (you pull it from)<br>- int pull_coroutine&lt;int&gt;::get()<br>- pull_co=
routine&lt;int&gt;::operator()() // no int as argument!<br><br>push_corouti=
ne&lt; int &gt; =3D=3D you transfer an int to the other context (you push i=
t to)<br>
- push_coroutine&lt;int&gt;::operator()( int)<br>// no push_coroutine::get(=
) !<br><br>pull_coroutine and push_coroutine occur always as pair<br>

<p></p>

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

--e89a8fb1f7a64bfe0504d8ba9883--

.

--e89a8fb20334e72cb904d8baad62
Content-Type: text/plain; charset=ISO-8859-1

2013/3/25 Denis Bredelet <denisgoogle@bredelet.com>

> My concern with:
>
> std::pull_coroutine <int> c( [&](std::push_coroutine <int> & c) {
>
>
push_coroutine<int> c([&](pull_coroutine<int> & c) { - is also possible


> is that the type of the push_coroutine is not indicated in the
> pull_coroutine, shouldn't it be std::pull_coroutine <int(int)>?
>

I'm not sure because pull_coroutine <int(int)> would imply a function of
signature int(int) (might confuse users?)

--

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



--e89a8fb20334e72cb904d8baad62
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">2013/3/25 Denis Bredelet <span dir=3D"ltr">&lt;<=
a href=3D"mailto:denisgoogle@bredelet.com" target=3D"_blank">denisgoogle@br=
edelet.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>My concern with:</div>
 =09
=09
=09
  <blockquote style=3D"margin:0 0 0 40px;border:none;padding:0px"><div><spa=
n style=3D"font-size:9pt;font-family:CMTT9">std::pull_coroutine &lt;</span>=
<span style=3D"font-size:9pt;font-family:CMTT9;color:rgb(0,0,255)">int</spa=
n><span style=3D"font-size:9pt;font-family:CMTT9">&gt; c(
[&amp;](std::push_coroutine &lt;</span><span style=3D"font-size:9pt;font-fa=
mily:CMTT9;color:rgb(0,0,255)">int</span><span style=3D"font-size:9pt;font-=
family:CMTT9">&gt; &amp; c) {</span></div></blockquote></blockquote><div><b=
r>
push_coroutine&lt;int&gt; c([&amp;](pull_coroutine&lt;int&gt; &amp; c) { - =
is also possible<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div=
>is that the type of the push_coroutine is not indicated in the pull_corout=
ine, shouldn&#39;t it be std::pull_coroutine &lt;int(int)&gt;?<br>
</div></blockquote></div><br>I&#39;m not sure because pull_coroutine &lt;in=
t(int)&gt; would imply a function of signature int(int) (might confuse user=
s?)<br>

<p></p>

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

--e89a8fb20334e72cb904d8baad62--

.

On Fri, Mar 22, 2013 at 5:16 AM, Oliver Kowalke
<oliver.kowalke@gmail.com> wrote:
> I'm currently working to support checkpointing of coroutines - I think it
> would be useful too?!
> Should I add it to the proposal?

No. The committee won't reject such a proposal because it is missing a
particular feature. They will simply ask that it be added if they care
about it.

OTOH, the committee will reject the proposal if they don't understand
what coroutines are and what the motivation is for adding them to the
C++ standard or a C++ standard technical specification.

If I were you I'd spend all the time between now and the Bristol
meeting working on your introductory material, adding references to
both current coroutine implementations and the general literature. Be
sure do dig out references to Knuth and other pioneers. Remember that
committee members come from a wide range of backgrounds. Some may be
deeply familiar with coroutines, some may have never heard of them.

And whatever else you do, submit the paper. There is nothing worse
that promising a paper on a public list like this one, and then not
delivering it. Since it is a late paper, you can just sent it to me
directly. And don't wait until the last minute. If you improve the
paper later, just send that along.

HTH,

--Beman

--

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



.

--089e0149d0b29906a204d8e3b834
Content-Type: text/plain; charset=ISO-8859-1

Here is the entire thing as working code in C# which already has the await
mechanism. The iterate_tree function works exactly the same as with the
coroutines.

Obviously the compiler needs to create an object or a side-stack to hold
the state of these functions while they are paused, but that is no
different from the coroutines AFAICT. The Task object that I use here to
control the process would be replaced with a future. The future class
doesn't do much more than store pointers to the code and the data of the
resumable function, so the added complexity should be small if the compiler
can eliminate any unused features included in std::future.


using System;
using System.Threading.Tasks;

namespace corot_test
{
    class multi_return<T>
    {
        T retval;
        public Task resumer;

        static Action do_nothing = () => { };

        public async Task put(T _retval)
        {
            retval = _retval;

            resumer = new Task(do_nothing);
            await resumer;
            resumer = null;
        }

        public void work()
        {
            resumer.RunSynchronously();
        }

        public T get()
        {
            return retval;
        }
    }

    class node<T>
    {
        public node(node<T> _left, T _value, node<T> _right) { left =
_left; right = _right; value = _value; }
        public node(T _value) { left = null; right = null; value = _value; }

        public node<T> left;
        public node<T> right;
        public T value;

        public async Task iterate_tree(multi_return<T> mr)
        {
            if (left != null)
                await left.iterate_tree(mr);

            await mr.put(value);

            if (right != null)
                await right.iterate_tree(mr);
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var t = new node<int>(new node<int>(3), 5, new node<int>(new
node<int>(7), 9, new node<int>(null, 11, new node<int>(13))));

            var mr = new multi_return<int>();

            t.iterate_tree(mr); // run till the first mr.put

            for (; mr.resumer != null; mr.work())
            {
                Console.WriteLine("Next Result {0}", mr.get());
            }

            Console.WriteLine("Done.");
        }
    }
}

output:
Next Result 3
Next Result 5
Next Result 7
Next Result 9
Next Result 11
Next Result 13
Done.




On Mon, Mar 25, 2013 at 6:13 AM, minchul park <summerlight00@gmail.com>wrote:

> No. Oliver's point seems to be something similar to differences between
> generator and coroutine. See below psuedo codes:
>
> # if python supports coroutine...
> def iterate_tree(coro, node):
>   if node:
>     iterate_tree(coro, node.left)
>     coro(node.value)
>     iterate_tree(coro, node.right)
>
> # with current python generator
> def iterate_tree(node):
>   if node:
>     for child in iterate_tree(node.left): # implicitly creates generator
> object
>       yield child
>     yield node.value
>     for child in iterate_tree(node.right): # also creates
>       yield child
>
> It's fairly tedious job to efficiently implement something like above code
> with generator.
>
> Adapting N3564 to this problem makes it even worse - you need to make
> future object for every items - though the purpose of proposal is support
> asynchronous job rather than enhancing control flow.
>
> I think most parts of N3564 can be covered by solution built on
> coroutine(or context switching primitive), without introducing additional
> language complexity.
>
>
> On Mon, Mar 25, 2013 at 11:25 AM, Michael Bruck <bruck.michael@gmail.com>wrote:
>
>>
>> On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <oliver.kowalke@gmail.com
>> > wrote:
>>
>>> it does not provide some kind of escape-and-reenter of loops
>>
>>
>> If I understand this correctly you mean something like this:
>>
>> std :: coroutine <int() > c (
>>    [&]( std :: coroutine <void(int) > & c ){
>>
>>     for (int i = 0; i < 10; ++i)
>>        c(i);
>> });
>>
>> int ret = 0;
>> for (; c ; c ())
>>   ret += c . get ();
>>
>> With await you should be able to write a helper class multi_return<T>
>> such that:
>>
>> future<void> corot(multi_return<int> & mr) resumable
>> {
>>     for (int i = 0; i < 10; ++i)
>>        await mr.set(i);
>>
>>     mr.terminate();
>> }
>>
>> multi_return<int> mr;
>>
>> corot(mr);
>>
>> int ret = 0;
>> while (mr.running())
>>   ret += mr.get();
>>
>>
>> The set() and get() methods on multi_return<T> can control each other via
>> some gadgets from the #include <future>. The key here is that due to await
>> compiler magic corot() returns as soon as it encounters a blocking await
>> and is afterwards restarted at the await once the blocking ended. To
>> implement the multi-return functionality you use the await to pause the
>> function once you found the first return value and resume it once this was
>> consumed via the get() method.
>>
>>
>> Michael
>>
>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>>
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>>
>>
>>
>
>
>
> --
> Min-chul Park (summerlight00@gmail.com / http://summerlight.tistory.com)
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3g6ZIWedGJ8/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>

--

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



--089e0149d0b29906a204d8e3b834
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style>Here is the entire thing as working code in C# =
which already has the await mechanism. The iterate_tree function works exac=
tly the same as with the coroutines.</div><div style><br></div><div style>
Obviously the compiler needs to create an object or a side-stack to hold th=
e state of these functions while they are paused, but that is no different =
from the coroutines AFAICT. The Task object that I use here to control the =
process would be replaced with a future. The future class doesn&#39;t do mu=
ch more than store pointers to the code and the data of the resumable funct=
ion, so the added complexity should be small if the compiler can eliminate =
any unused features included in std::future.</div>
<div><div><br></div><div><br></div><div><div>using System;</div><div>using =
System.Threading.Tasks;</div><div><br></div><div>namespace corot_test</div>=
<div>{</div><div>=A0 =A0 class multi_return&lt;T&gt;</div><div>=A0 =A0 {</d=
iv><div>
=A0 =A0 =A0 =A0 T retval;</div><div>=A0 =A0 =A0 =A0 public Task resumer;</d=
iv><div><br></div><div>=A0 =A0 =A0 =A0 static Action do_nothing =3D () =3D&=
gt; { };</div><div>=A0 =A0 =A0 =A0=A0</div><div>=A0 =A0 =A0 =A0 public asyn=
c Task put(T _retval)</div><div>=A0 =A0 =A0 =A0 {</div>
<div>=A0 =A0 =A0 =A0 =A0 =A0 retval =3D _retval;</div><div><br></div><div>=
=A0 =A0 =A0 =A0 =A0 =A0 resumer =3D new Task(do_nothing);</div><div>=A0 =A0=
 =A0 =A0 =A0 =A0 await resumer;</div><div>=A0 =A0 =A0 =A0 =A0 =A0 resumer =
=3D null;</div><div>=A0 =A0 =A0 =A0 }</div><div><br></div><div>
=A0 =A0 =A0 =A0 public void work()</div><div>=A0 =A0 =A0 =A0 {</div><div>=
=A0 =A0 =A0 =A0 =A0 =A0 resumer.RunSynchronously();</div><div>=A0 =A0 =A0 =
=A0 }</div><div><br></div><div>=A0 =A0 =A0 =A0 public T get()</div><div>=A0=
 =A0 =A0 =A0 {</div><div>=A0 =A0 =A0 =A0 =A0 =A0 return retval;</div>
<div>=A0 =A0 =A0 =A0 }</div><div>=A0 =A0 }</div><div><br></div><div>=A0 =A0=
 class node&lt;T&gt;</div><div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 public n=
ode(node&lt;T&gt; _left, T _value, node&lt;T&gt; _right) { left =3D _left; =
right =3D _right; value =3D _value; }</div>
<div>=A0 =A0 =A0 =A0 public node(T _value) { left =3D null; right =3D null;=
 value =3D _value; }</div><div><br></div><div>=A0 =A0 =A0 =A0 public node&l=
t;T&gt; left;</div><div>=A0 =A0 =A0 =A0 public node&lt;T&gt; right;</div><d=
iv>=A0 =A0 =A0 =A0 public T value;</div>
<div><br></div><div>=A0 =A0 =A0 =A0 public async Task iterate_tree(multi_re=
turn&lt;T&gt; mr)</div><div>=A0 =A0 =A0 =A0 {</div><div>=A0 =A0 =A0 =A0 =A0=
 =A0 if (left !=3D null)</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 await le=
ft.iterate_tree(mr);</div><div><br></div><div>
=A0 =A0 =A0 =A0 =A0 =A0 await mr.put(value);</div><div><br></div><div>=A0 =
=A0 =A0 =A0 =A0 =A0 if (right !=3D null)</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 await right.iterate_tree(mr);</div><div>=A0 =A0 =A0 =A0 }</div><div=
>=A0 =A0 }</div><div><br></div><div>=A0 =A0 class Program</div>
<div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 static void Main(string[] args)</d=
iv><div>=A0 =A0 =A0 =A0 {</div><div>=A0 =A0 =A0 =A0 =A0 =A0 var t =3D new n=
ode&lt;int&gt;(new node&lt;int&gt;(3), 5, new node&lt;int&gt;(new node&lt;i=
nt&gt;(7), 9, new node&lt;int&gt;(null, 11, new node&lt;int&gt;(13))));</di=
v>
<div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 var mr =3D new multi_return&lt;=
int&gt;();</div><div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 t.iterate_tree(=
mr); // run till the first mr.put</div><div><br></div><div>=A0 =A0 =A0 =A0 =
=A0 =A0 for (; mr.resumer !=3D null; mr.work())</div>
<div>=A0 =A0 =A0 =A0 =A0 =A0 {</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Co=
nsole.WriteLine(&quot;Next Result {0}&quot;, mr.get());</div><div>=A0 =A0 =
=A0 =A0 =A0 =A0 }</div><div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 Console.=
WriteLine(&quot;Done.&quot;);</div><div>=A0 =A0 =A0 =A0 }</div>
<div>=A0 =A0 }</div><div>}</div></div><div><br></div></div><div style>outpu=
t:</div><div><div>Next Result 3</div><div>Next Result 5</div><div>Next Resu=
lt 7</div><div>Next Result 9</div><div>Next Result 11</div><div>Next Result=
 13</div>
<div>Done.</div></div><div><br></div><div><br></div><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote">On Mon, Mar 25, 2013 at 6:13 AM, min=
chul park <span dir=3D"ltr">&lt;<a href=3D"mailto:summerlight00@gmail.com" =
target=3D"_blank">summerlight00@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">No. Oliver&#39;s point seems to be someth=
ing similar to differences between generator and coroutine. See below psued=
o codes:<div>
<br></div><div># if python supports coroutine...</div><div>def iterate_tree=
(coro, node):<br>
<div>=A0 if node:</div><div>=A0 =A0 iterate_tree(coro, node.left)</div></di=
v><div>=A0 =A0 coro(node.value)</div><div>=A0 =A0 iterate_tree(coro, node.r=
ight)</div><div><br></div><div># with current python generator</div>
<div>def iterate_tree(node):</div><div>=A0 if node:</div><div>=A0 =A0 for c=
hild in iterate_tree(node.left): # implicitly creates generator object</div=
><div>=A0 =A0 =A0 yield child</div><div>=A0 =A0 yield node.value</div>
<div>=A0 =A0 for child in iterate_tree(node.right): # also creates</div><di=
v>=A0 =A0 =A0 yield child</div><div><br></div><div>It&#39;s fairly tedious =
job to efficiently implement something like above code with generator.</div=
>
<div><br></div><div>Adapting N3564 to this problem makes it even worse - yo=
u need to make future object for every items - though the purpose of propos=
al is support asynchronous job rather than enhancing control flow.</div>

<div><br></div><div>I think most parts of N3564 can be covered by solution =
built on coroutine(or context switching primitive), without introducing add=
itional language complexity.</div></div><div class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Mar 25, 2=
013 at 11:25 AM, Michael Bruck <span dir=3D"ltr">&lt;<a href=3D"mailto:bruc=
k.michael@gmail.com" target=3D"_blank">bruck.michael@gmail.com</a>&gt;</spa=
n> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div><div class=3D"h5">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div><br><div class=3D"gmail_qu=
ote">On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <span dir=3D"ltr">&lt;=
<a href=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">oliver.kowalk=
e@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"> it does not provide some kind of escape-and-reenter of lo=
ops</blockquote>


</div><div class=3D"gmail_extra"><br></div></div>If I understand this corre=
ctly you mean something like this:</div><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">std :: coroutine &l=
t;int() &gt; c (</div>

<div>
<div class=3D"gmail_extra">=A0 [&amp;]( std :: coroutine &lt;void(int) &gt;=
 &amp; c ){</div><div class=3D"gmail_extra"><br></div></div><div class=3D"g=
mail_extra">=A0 =A0 for (int i =3D 0; i &lt; 10; ++i)</div><div class=3D"gm=
ail_extra">


=A0 =A0 =A0 =A0c(i);</div><div class=3D"gmail_extra">});<br></div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">int ret =3D 0;</div>=
<div class=3D"gmail_extra">for (; c ; c ())</div><div class=3D"gmail_extra"=
>=A0 ret +=3D c . get ();</div>


<br></div><div class=3D"gmail_extra">With await you should be able to write=
 a helper class multi_return&lt;T&gt; such that:</div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">future&lt;void&gt; corot(multi_r=
eturn&lt;int&gt; &amp; mr) resumable<br>


</div><div class=3D"gmail_extra">{</div><div class=3D"gmail_extra">=A0 =A0 =
for (int i =3D 0; i &lt; 10; ++i)</div><div class=3D"gmail_extra">=A0 =A0 =
=A0 =A0await mr.set(i);</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">
=A0 =A0 mr.terminate();</div><div class=3D"gmail_extra">}</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">multi_return&lt;int&g=
t; mr;<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">
corot(mr);</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra"><div class=3D"gmail_extra">int ret =3D 0;</div><div class=3D"gmail_ext=
ra">while (mr.running())</div><div class=3D"gmail_extra">=A0 ret +=3D mr.ge=
t();</div>
<div><br></div></div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">The set() and get() methods on multi_return&lt;T&gt; can control =
each other via some gadgets from the #include &lt;future&gt;. The key here =
is that due to await compiler magic corot() returns as soon as it encounter=
s a blocking await and is afterwards restarted at the await once the blocki=
ng ended. To implement the multi-return functionality you use the await to =
pause the function once you found the first return value and resume it once=
 this was consumed via the get() method.</div>

<span><font color=3D"#888888">
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">Michael</div><div class=3D"gmail_extra"><br></div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">
<br></div></font></span></div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<div class=3D"im"><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></div></blockquote></div><span class=3D""><font color=3D"#88888=
8"><br><br clear=3D"all"><div><br></div>-- <br><div>Min-chul Park (<a href=
=3D"mailto:summerlight00@gmail.com" target=3D"_blank">summerlight00@gmail.c=
om</a>=A0/ <a href=3D"http://summerlight.tistory.com/" target=3D"_blank">ht=
tp://summerlight.tistory.com</a>)</div>


</font></span></div><div class=3D""><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/3g6ZIWedGJ8/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3g=
6ZIWedGJ8/unsubscribe?hl=3Den</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--089e0149d0b29906a204d8e3b834--

.

--089e0149d0b2cdf3d304d8e3d5b8
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <oliver.kowalke@gmail.com>wrote:

> As N3564 describes 'After suspending, a resumable function may be resumed
> by the scheduling logic of the runtime...' - seams not to be
> equivalent cooperative scheduling.
>

Sorry, I didn't reply to this part of the question before. The scheduling
mechanisms are described in N3558. The scheduling depends on the future
that you are waiting for (see the discussion of .then in that document). So
this future would just run the rest of the function synchronously to
simulate the coroutine behaviour. The C# sample in my other mail to Minchul
does exactly that, the entire program is single-threaded.

Michael

--

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



--089e0149d0b2cdf3d304d8e3d5b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">oliver.kowalke@gma=
il.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div id=3D":zk">As N3564 describes &#39;After suspending, =
a resumable function may be resumed by the scheduling logic of the runtime.=
...&#39; - seams not to be<br>

equivalent cooperative scheduling.</div></blockquote></div><br>Sorry, I did=
n&#39;t reply to this part of the question before. The scheduling mechanism=
s are described in=A0N3558. The scheduling depends on the future that you a=
re waiting for (see the discussion of .then in that document). So this futu=
re would just run the rest of the function synchronously to simulate the co=
routine behaviour. The C# sample in my other mail to Minchul does exactly t=
hat, the entire program is single-threaded.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style>Micha=
el</div></div>

<p></p>

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

--089e0149d0b2cdf3d304d8e3d5b8--

.

On Wed, Mar 27, 2013 at 8:21 AM, Michael Bruck <bruck.michael@gmail.com> wrote:
> Here is the entire thing as working code in C# which already has the await
> mechanism. The iterate_tree function works exactly the same as with the
> coroutines.
>
> Obviously the compiler needs to create an object or a side-stack to hold the
> state of these functions while they are paused, but that is no different
> from the coroutines AFAICT. The Task object that I use here to control the
> process would be replaced with a future. The future class doesn't do much
> more than store pointers to the code and the data of the resumable function,
> so the added complexity should be small if the compiler can eliminate any
> unused features included in std::future.
>
>
> using System;
> using System.Threading.Tasks;
>
> namespace corot_test
> {
>     class multi_return<T>
>     {
>         T retval;
>         public Task resumer;
>
>         static Action do_nothing = () => { };
>
>         public async Task put(T _retval)
>         {
>             retval = _retval;
>
>             resumer = new Task(do_nothing);
>             await resumer;
>             resumer = null;
>         }
>
>         public void work()
>         {
>             resumer.RunSynchronously();
>         }
>
>         public T get()
>         {
>             return retval;
>         }
>     }
>
>     class node<T>
>     {
>         public node(node<T> _left, T _value, node<T> _right) { left = _left;
> right = _right; value = _value; }
>         public node(T _value) { left = null; right = null; value = _value; }
>
>         public node<T> left;
>         public node<T> right;
>         public T value;
>
>         public async Task iterate_tree(multi_return<T> mr)
>         {
>             if (left != null)
>                 await left.iterate_tree(mr);
>
>             await mr.put(value);
>
>             if (right != null)
>                 await right.iterate_tree(mr);
>         }
>     }
>

This means that yield is O(N) where N is the average depth of the
tree, instead of of O(1), which changes the complexity of the
solution. Additionally you have to change the visiting algorithm to
yield at every level, you can't reuse an existing enumeration
interface that takes a visiting function, which is a significant
limitation. Finally you have to heap allocate both the future control
block and the generator activation frame for every depth level.

The two proposals are not equivalent.

-- gpd

--

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



.

--e89a8f83a34b2ba98604d8e6a34a
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Mar 27, 2013 at 5:21 PM, Michael Bruck <bruck.michael@gmail.com>wrote:

> Here is the entire thing as working code in C# which already has the await
> mechanism. The iterate_tree function works exactly the same as with the
> coroutines.
>

 Your code "emulates" its functionality. In the behind of scene, it works
in completely different way. async/await is based on code transformation
rather than user-level execution context management, right? Then it's
completely different. Imagine that your OS can't schedule user thread
because it is running a function that is not marked as "resumable". Without
managing full execution context, you can't do that.

 Providing tool for execution context is essential in modern concurrent
programming environment. Though it's hard to implement it as first-class
continuation, many modern languages support it as limited format (ex.
goroutine in go, task in rust) in one way or another, and even in language
like python, some implementation (greenlet, stackless, pypy ...) tries to
support coroutine.


> Obviously the compiler needs to create an object or a side-stack to hold
> the state of these functions while they are paused, but that is no
> different from the coroutines AFAICT.
>

 Nope. Tree iteration with coroutine never requires to allocates any object
to solely control its execution flow. See the below code:

def iterate_tree(coro, node):
  if node: # null check
    iterate_tree(coro, node.left) # normal function call
    coro(node.value) # context switch
    iterate_tree(coro, node.right) # normal function call

 Only one allocation for coroutine itself - before iteration - is required.

The Task object that I use here to control the process would be replaced
> with a future. The future class doesn't do much more than store pointers to
> the code and the data of the resumable function, so the added complexity
> should be small if the compiler can eliminate any unused features included
> in std::future.
>

Data size of resumable function can be larger than std::future itself,
which leads to dynamic allocation. Since memory allocation in C++ is more
expensive than C#, it can't be easily neglected.


>
>
> using System;
> using System.Threading.Tasks;
>
> namespace corot_test
> {
>     class multi_return<T>
>     {
>         T retval;
>         public Task resumer;
>
>         static Action do_nothing = () => { };
>
>         public async Task put(T _retval)
>         {
>             retval = _retval;
>
>             resumer = new Task(do_nothing);
>             await resumer;
>             resumer = null;
>         }
>
>         public void work()
>         {
>             resumer.RunSynchronously();
>         }
>
>         public T get()
>         {
>             return retval;
>         }
>     }
>
>     class node<T>
>     {
>         public node(node<T> _left, T _value, node<T> _right) { left =
> _left; right = _right; value = _value; }
>         public node(T _value) { left = null; right = null; value = _value;
> }
>
>         public node<T> left;
>         public node<T> right;
>         public T value;
>
>         public async Task iterate_tree(multi_return<T> mr)
>         {
>             if (left != null)
>                 await left.iterate_tree(mr);
>
>             await mr.put(value);
>
>             if (right != null)
>                 await right.iterate_tree(mr);
>         }
>     }
>
>     class Program
>     {
>         static void Main(string[] args)
>         {
>             var t = new node<int>(new node<int>(3), 5, new node<int>(new
> node<int>(7), 9, new node<int>(null, 11, new node<int>(13))));
>
>             var mr = new multi_return<int>();
>
>             t.iterate_tree(mr); // run till the first mr.put
>
>             for (; mr.resumer != null; mr.work())
>             {
>                 Console.WriteLine("Next Result {0}", mr.get());
>             }
>
>             Console.WriteLine("Done.");
>         }
>     }
> }
>
> output:
> Next Result 3
> Next Result 5
> Next Result 7
> Next Result 9
> Next Result 11
> Next Result 13
> Done.
>
>
>
>
> On Mon, Mar 25, 2013 at 6:13 AM, minchul park <summerlight00@gmail.com>wrote:
>
>> No. Oliver's point seems to be something similar to differences between
>> generator and coroutine. See below psuedo codes:
>>
>> # if python supports coroutine...
>> def iterate_tree(coro, node):
>>   if node:
>>     iterate_tree(coro, node.left)
>>     coro(node.value)
>>     iterate_tree(coro, node.right)
>>
>> # with current python generator
>> def iterate_tree(node):
>>   if node:
>>     for child in iterate_tree(node.left): # implicitly creates generator
>> object
>>       yield child
>>     yield node.value
>>     for child in iterate_tree(node.right): # also creates
>>       yield child
>>
>> It's fairly tedious job to efficiently implement something like above
>> code with generator.
>>
>> Adapting N3564 to this problem makes it even worse - you need to make
>> future object for every items - though the purpose of proposal is support
>> asynchronous job rather than enhancing control flow.
>>
>> I think most parts of N3564 can be covered by solution built on
>> coroutine(or context switching primitive), without introducing additional
>> language complexity.
>>
>>
>> On Mon, Mar 25, 2013 at 11:25 AM, Michael Bruck <bruck.michael@gmail.com>wrote:
>>
>>>
>>> On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <
>>> oliver.kowalke@gmail.com> wrote:
>>>
>>>> it does not provide some kind of escape-and-reenter of loops
>>>
>>>
>>> If I understand this correctly you mean something like this:
>>>
>>> std :: coroutine <int() > c (
>>>    [&]( std :: coroutine <void(int) > & c ){
>>>
>>>     for (int i = 0; i < 10; ++i)
>>>        c(i);
>>> });
>>>
>>> int ret = 0;
>>> for (; c ; c ())
>>>   ret += c . get ();
>>>
>>> With await you should be able to write a helper class multi_return<T>
>>> such that:
>>>
>>> future<void> corot(multi_return<int> & mr) resumable
>>> {
>>>     for (int i = 0; i < 10; ++i)
>>>        await mr.set(i);
>>>
>>>     mr.terminate();
>>> }
>>>
>>> multi_return<int> mr;
>>>
>>> corot(mr);
>>>
>>> int ret = 0;
>>> while (mr.running())
>>>   ret += mr.get();
>>>
>>>
>>> The set() and get() methods on multi_return<T> can control each other
>>> via some gadgets from the #include <future>. The key here is that due to
>>> await compiler magic corot() returns as soon as it encounters a blocking
>>> await and is afterwards restarted at the await once the blocking ended. To
>>> implement the multi-return functionality you use the await to pause the
>>> function once you found the first return value and resume it once this was
>>> consumed via the get() method.
>>>
>>>
>>> Michael
>>>
>>>
>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>>
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>>>
>>>
>>>
>>
>>
>>
>> --
>> Min-chul Park (summerlight00@gmail.com / http://summerlight.tistory.com)
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3g6ZIWedGJ8/unsubscribe?hl=en
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>>
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>>
>>
>>
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>



--
Min-chul Park (summerlight00@gmail.com / http://summerlight.tistory.com)

--

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



--e89a8f83a34b2ba98604d8e6a34a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Mar 27, 2013 at 5:21 PM, Michael Bruck <span dir=3D"ltr">&l=
t;<a href=3D"mailto:bruck.michael@gmail.com" target=3D"_blank">bruck.michae=
l@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>Here is the entire thing as working =
code in C# which already has the await mechanism. The iterate_tree function=
 works exactly the same as with the coroutines.</div>
</div></blockquote><div><br></div><div style>=A0Your code &quot;emulates&qu=
ot; its functionality. In the behind of scene, it works in completely diffe=
rent way. async/await is based on code transformation rather than user-leve=
l execution context management, right? Then it&#39;s completely different. =
Imagine that your OS can&#39;t schedule user thread because it is running a=
 function that is not marked as &quot;resumable&quot;. Without managing ful=
l execution context, you can&#39;t do that.</div>
<div style><br></div><div style>=A0Providing tool for execution context is =
essential in modern concurrent programming environment. Though it&#39;s har=
d to implement it as first-class continuation, many modern languages suppor=
t it as limited format (ex. goroutine in go, task in rust) in one way or an=
other, and even in language like python, some implementation (greenlet, sta=
ckless, pypy ...) tries to support coroutine.=A0</div>
<div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>
Obviously the compiler needs to create an object or a side-stack to hold th=
e state of these functions while they are paused, but that is no different =
from the coroutines AFAICT.</div></div></blockquote><div><br></div><div sty=
le>
=A0Nope. Tree iteration with coroutine never requires to allocates any obje=
ct to solely control its execution flow. See the below code:</div><div styl=
e><br></div><div style><div>def iterate_tree(coro, node):</div><div>=A0 if =
node: # null check</div>
<div>=A0 =A0 iterate_tree(coro, node.left) # normal function call</div><div=
>=A0 =A0 coro(node.value) # context switch</div><div>=A0 =A0 iterate_tree(c=
oro, node.right) # normal function call</div></div><div>=A0</div><div style=
>=A0Only one allocation for coroutine itself - before iteration - is requir=
ed.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><div> The Task object that=
 I use here to control the process would be replaced with a future. The fut=
ure class doesn&#39;t do much more than store pointers to the code and the =
data of the resumable function, so the added complexity should be small if =
the compiler can eliminate any unused features included in std::future.</di=
v>
</div></blockquote><div><br></div><div style>Data size of resumable functio=
n can be larger than std::future itself, which leads to dynamic allocation.=
 Since memory allocation in C++ is more expensive than C#, it can&#39;t be =
easily neglected.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr">
<div><div><br></div><div><br></div><div><div>using System;</div><div>using =
System.Threading.Tasks;</div><div><br></div><div>namespace corot_test</div>=
<div>{</div><div>=A0 =A0 class multi_return&lt;T&gt;</div><div>=A0 =A0 {</d=
iv>
<div>
=A0 =A0 =A0 =A0 T retval;</div><div>=A0 =A0 =A0 =A0 public Task resumer;</d=
iv><div><br></div><div>=A0 =A0 =A0 =A0 static Action do_nothing =3D () =3D&=
gt; { };</div><div>=A0 =A0 =A0 =A0=A0</div><div>=A0 =A0 =A0 =A0 public asyn=
c Task put(T _retval)</div><div>=A0 =A0 =A0 =A0 {</div>

<div>=A0 =A0 =A0 =A0 =A0 =A0 retval =3D _retval;</div><div><br></div><div>=
=A0 =A0 =A0 =A0 =A0 =A0 resumer =3D new Task(do_nothing);</div><div>=A0 =A0=
 =A0 =A0 =A0 =A0 await resumer;</div><div>=A0 =A0 =A0 =A0 =A0 =A0 resumer =
=3D null;</div><div>=A0 =A0 =A0 =A0 }</div><div><br></div><div>

=A0 =A0 =A0 =A0 public void work()</div><div>=A0 =A0 =A0 =A0 {</div><div>=
=A0 =A0 =A0 =A0 =A0 =A0 resumer.RunSynchronously();</div><div>=A0 =A0 =A0 =
=A0 }</div><div><br></div><div>=A0 =A0 =A0 =A0 public T get()</div><div>=A0=
 =A0 =A0 =A0 {</div><div>=A0 =A0 =A0 =A0 =A0 =A0 return retval;</div>

<div>=A0 =A0 =A0 =A0 }</div><div>=A0 =A0 }</div><div><br></div><div>=A0 =A0=
 class node&lt;T&gt;</div><div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 public n=
ode(node&lt;T&gt; _left, T _value, node&lt;T&gt; _right) { left =3D _left; =
right =3D _right; value =3D _value; }</div>

<div>=A0 =A0 =A0 =A0 public node(T _value) { left =3D null; right =3D null;=
 value =3D _value; }</div><div><br></div><div>=A0 =A0 =A0 =A0 public node&l=
t;T&gt; left;</div><div>=A0 =A0 =A0 =A0 public node&lt;T&gt; right;</div><d=
iv>=A0 =A0 =A0 =A0 public T value;</div>

<div><br></div><div>=A0 =A0 =A0 =A0 public async Task iterate_tree(multi_re=
turn&lt;T&gt; mr)</div><div>=A0 =A0 =A0 =A0 {</div><div>=A0 =A0 =A0 =A0 =A0=
 =A0 if (left !=3D null)</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 await le=
ft.iterate_tree(mr);</div><div><br></div>
<div>
=A0 =A0 =A0 =A0 =A0 =A0 await mr.put(value);</div><div><br></div><div>=A0 =
=A0 =A0 =A0 =A0 =A0 if (right !=3D null)</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 await right.iterate_tree(mr);</div><div>=A0 =A0 =A0 =A0 }</div><div=
>=A0 =A0 }</div><div><br></div><div>=A0 =A0 class Program</div>

<div>=A0 =A0 {</div><div>=A0 =A0 =A0 =A0 static void Main(string[] args)</d=
iv><div>=A0 =A0 =A0 =A0 {</div><div>=A0 =A0 =A0 =A0 =A0 =A0 var t =3D new n=
ode&lt;int&gt;(new node&lt;int&gt;(3), 5, new node&lt;int&gt;(new node&lt;i=
nt&gt;(7), 9, new node&lt;int&gt;(null, 11, new node&lt;int&gt;(13))));</di=
v>

<div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 var mr =3D new multi_return&lt;=
int&gt;();</div><div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 t.iterate_tree(=
mr); // run till the first mr.put</div><div><br></div><div>=A0 =A0 =A0 =A0 =
=A0 =A0 for (; mr.resumer !=3D null; mr.work())</div>

<div>=A0 =A0 =A0 =A0 =A0 =A0 {</div><div>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Co=
nsole.WriteLine(&quot;Next Result {0}&quot;, mr.get());</div><div>=A0 =A0 =
=A0 =A0 =A0 =A0 }</div><div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 Console.=
WriteLine(&quot;Done.&quot;);</div><div>=A0 =A0 =A0 =A0 }</div>

<div>=A0 =A0 }</div><div>}</div></div><div><br></div></div><div>output:</di=
v><div><div>Next Result 3</div><div>Next Result 5</div><div>Next Result 7</=
div><div>Next Result 9</div><div>Next Result 11</div><div>Next Result 13</d=
iv>

<div>Done.</div></div><div><br></div><div><br></div><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Mar 2=
5, 2013 at 6:13 AM, minchul park <span dir=3D"ltr">&lt;<a href=3D"mailto:su=
mmerlight00@gmail.com" target=3D"_blank">summerlight00@gmail.com</a>&gt;</s=
pan> wrote:<br>

</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr">No. Ol=
iver&#39;s point seems to be something similar to differences between gener=
ator and coroutine. See below psuedo codes:<div>

<br></div><div># if python supports coroutine...</div><div>def iterate_tree=
(coro, node):<br>
<div>=A0 if node:</div><div>=A0 =A0 iterate_tree(coro, node.left)</div></di=
v><div>=A0 =A0 coro(node.value)</div><div>=A0 =A0 iterate_tree(coro, node.r=
ight)</div><div><br></div><div># with current python generator</div>
<div>def iterate_tree(node):</div><div>=A0 if node:</div><div>=A0 =A0 for c=
hild in iterate_tree(node.left): # implicitly creates generator object</div=
><div>=A0 =A0 =A0 yield child</div><div>=A0 =A0 yield node.value</div>
<div>=A0 =A0 for child in iterate_tree(node.right): # also creates</div><di=
v>=A0 =A0 =A0 yield child</div><div><br></div><div>It&#39;s fairly tedious =
job to efficiently implement something like above code with generator.</div=
>
<div><br></div><div>Adapting N3564 to this problem makes it even worse - yo=
u need to make future object for every items - though the purpose of propos=
al is support asynchronous job rather than enhancing control flow.</div>


<div><br></div><div>I think most parts of N3564 can be covered by solution =
built on coroutine(or context switching primitive), without introducing add=
itional language complexity.</div></div><div class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote"><div><div>On Mon, Mar 25, 2013 at 11:25 =
AM, Michael Bruck <span dir=3D"ltr">&lt;<a href=3D"mailto:bruck.michael@gma=
il.com" target=3D"_blank">bruck.michael@gmail.com</a>&gt;</span> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div><div>
<div dir=3D"ltr"><div class=3D"gmail_extra"><div><br><div class=3D"gmail_qu=
ote">On Sun, Mar 24, 2013 at 3:08 PM, Oliver Kowalke <span dir=3D"ltr">&lt;=
<a href=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">oliver.kowalk=
e@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"> it does not provide some kind of escape-and-reenter of lo=
ops</blockquote>



</div><div class=3D"gmail_extra"><br></div></div>If I understand this corre=
ctly you mean something like this:</div><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra">std :: coroutine &l=
t;int() &gt; c (</div>


<div>
<div class=3D"gmail_extra">=A0 [&amp;]( std :: coroutine &lt;void(int) &gt;=
 &amp; c ){</div><div class=3D"gmail_extra"><br></div></div><div class=3D"g=
mail_extra">=A0 =A0 for (int i =3D 0; i &lt; 10; ++i)</div><div class=3D"gm=
ail_extra">



=A0 =A0 =A0 =A0c(i);</div><div class=3D"gmail_extra">});<br></div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">int ret =3D 0;</div>=
<div class=3D"gmail_extra">for (; c ; c ())</div><div class=3D"gmail_extra"=
>=A0 ret +=3D c . get ();</div>



<br></div><div class=3D"gmail_extra">With await you should be able to write=
 a helper class multi_return&lt;T&gt; such that:</div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">future&lt;void&gt; corot(multi_r=
eturn&lt;int&gt; &amp; mr) resumable<br>



</div><div class=3D"gmail_extra">{</div><div class=3D"gmail_extra">=A0 =A0 =
for (int i =3D 0; i &lt; 10; ++i)</div><div class=3D"gmail_extra">=A0 =A0 =
=A0 =A0await mr.set(i);</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">
=A0 =A0 mr.terminate();</div><div class=3D"gmail_extra">}</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">multi_return&lt;int&g=
t; mr;<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra">
corot(mr);</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ex=
tra"><div class=3D"gmail_extra">int ret =3D 0;</div><div class=3D"gmail_ext=
ra">while (mr.running())</div><div class=3D"gmail_extra">=A0 ret +=3D mr.ge=
t();</div>
<div><br></div></div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">The set() and get() methods on multi_return&lt;T&gt; can control =
each other via some gadgets from the #include &lt;future&gt;. The key here =
is that due to await compiler magic corot() returns as soon as it encounter=
s a blocking await and is afterwards restarted at the await once the blocki=
ng ended. To implement the multi-return functionality you use the await to =
pause the function once you found the first return value and resume it once=
 this was consumed via the get() method.</div>


<span><font color=3D"#888888">
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">Michael</div><div class=3D"gmail_extra"><br></div=
><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">
<br></div></font></span></div></div></div><div><div>

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<div><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></div></blockquote></div><span><font color=3D"#888888"><br><br =
clear=3D"all"><div><br></div>-- <br><div>Min-chul Park (<a href=3D"mailto:s=
ummerlight00@gmail.com" target=3D"_blank">summerlight00@gmail.com</a>=A0/ <=
a href=3D"http://summerlight.tistory.com/" target=3D"_blank">http://summerl=
ight.tistory.com</a>)</div>



</font></span></div></div></div><div><div><span class=3D""><font color=3D"#=
888888">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/3g6ZIWedGJ8/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/3g=
6ZIWedGJ8/unsubscribe?hl=3Den</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.</font></span><div class=3D"im"><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></div></blockquote></div><br></div></div><div class=3D""><div c=
lass=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div>Min-chul Park (<a href=3D"mailto:summerlight00@gmail.com" target=3D"_b=
lank">summerlight00@gmail.com</a>=A0/ <a href=3D"http://summerlight.tistory=
..com/" target=3D"_blank">http://summerlight.tistory.com</a>)</div>

</div></div>

<p></p>

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

--e89a8f83a34b2ba98604d8e6a34a--

.

--f46d0447f2a8d56f7e04d9ae0093
Content-Type: text/plain; charset=ISO-8859-1

2013/3/25 Beman Dawes <bdawes@acm.org>

> And whatever else you do, submit the paper. There is nothing worse
> that promising a paper on a public list like this one, and then not
> delivering it. Since it is a late paper, you can just sent it to me
> directly. And don't wait until the last minute. If you improve the
> paper later, just send that along.
>

done (additional email sent to you)

--

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



--f46d0447f2a8d56f7e04d9ae0093
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013=
/3/25 Beman Dawes <span dir=3D"ltr">&lt;<a href=3D"mailto:bdawes@acm.org" t=
arget=3D"_blank">bdawes@acm.org</a>&gt;</span><br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">

And whatever else you do, submit the paper. There is nothing worse<br>
that promising a paper on a public list like this one, and then not<br>
delivering it. Since it is a late paper, you can just sent it to me<br>
directly. And don&#39;t wait until the last minute. If you improve the<br>
paper later, just send that along.<br></blockquote></div><br></div><div cla=
ss=3D"gmail_extra">done (additional email sent to you)<br></div></div>

<p></p>

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

--f46d0447f2a8d56f7e04d9ae0093--

.

--e89a8ff1c9b8154f6c04d9dad43d
Content-Type: text/plain; charset=ISO-8859-1

2013/4/8 <cornedbee@google.com>

>
> On Friday, March 22, 2013 10:16:39 AM UTC+1, Oliver Kowalke wrote:
>>
>> I'm currently working to support checkpointing of coroutines - I think it
>> would be useful too?!
>> Should I add it to the proposal?
>>
>
> No, absolutely not. While checkpointing might be useful, I think it is far
> too complicated and dangerous to be added to the initial proposal. Adding
> checkpointing means you have to define what this means:
>
> checkpoint cp;
> std::coroutine< int() > c(
>    [&](std::coroutine< void( int) > & c) {
>       int i = 0;
>       cp = c.checkpoint(); // coroutine checkpoint
>       std::vector<int> v(5, 5);
>
>       while ( true) {
>          c( ++i);
> });
>
> c().get();
>
> c.rollback( cp);
>
> What happens to the vector on rollback? Is it destroyed and reconstructed?
>

destroyed and after resumeing the coroutine it is constructed again
(because the checkpoint was set before),


> Is its initialization skipped the second time around?
>

no


> Is this just undefined?
>

no


> Is it the same behavior as setjmp/longjmp exhibit? (I think setjmp/longjmp
> would be undefined in this case according to 18.10p4.)
>

I don't use setjmp/longjmp.



>
> In general, is checkpoint()/rollback() equivalent to setjmp and longjmp
> within the context of the coroutine, i.e. it only changes execution
> position, not values? Or would values be changed in some way?
>

code between the checkpoint and the last instruction in the coroutine-fn is
unwound if a rollback is done to the checkpoint (in your case std::vector<
int > gets destructed).
if the coroutine is then resumed it executes the instructions following
after the checpoint - in your case std::vector< int > is constructed.



>
> These seem to me to be non-trivial issues that would only muddle the
> proposal you have now. And I see no reason why checkpointing couldn't be
> added later in a separate proposal.
>

I've already some code - a proof of concept - which is working. As Beman
Daws already told I'll add this later to the proposal (I think if it is
working in boost.coroutine).

Oliver

--

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



--e89a8ff1c9b8154f6c04d9dad43d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013=
/4/8  <span dir=3D"ltr">&lt;<a href=3D"mailto:cornedbee@google.com" target=
=3D"_blank">cornedbee@google.com</a>&gt;</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 class=3D"im"><br>On Friday, March 22, 2013 10:16:39 AM UTC+1, Oliver K=
owalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I&#39;m curr=
ently working to support checkpointing of coroutines - I think it would be =
useful too?!<br>
Should I add it to the proposal?<br></blockquote><div><br></div></div><div>=
No, absolutely not. While checkpointing might be useful, I think it is far =
too complicated and dangerous to be added to the initial proposal. Adding c=
heckpointing means you have to define what this means:</div>
<div><br></div><div><div class=3D"im">checkpoint cp;<br>std::coroutine&lt; =
int() &gt; c(<br>=A0=A0 [&amp;](std::coroutine&lt; void( int) &gt; &amp; c)=
 {<br>=A0=A0=A0=A0=A0 int i =3D 0;<br>=A0=A0=A0=A0=A0 cp =3D c.checkpoint()=
; // coroutine checkpoint<br>
</div>=A0=A0=A0=A0=A0 std::vector&lt;int&gt; v(5, 5);<div class=3D"im"><br>=
=A0=A0=A0=A0=A0 while ( true) {<br>=A0=A0=A0=A0=A0=A0=A0=A0 c( ++i);<br>});=
<br><br></div>c().get();<br><br>c.rollback( cp);<br><br></div><div>What hap=
pens to the vector on rollback? Is it destroyed and reconstructed?</div>
</blockquote><div><br></div><div>destroyed and after resumeing the coroutin=
e it is constructed again (because the checkpoint was set before),<br></div=
><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Is its initialization skipped the second time around?</div></blockquot=
e><div><br></div><div>no<br></div><div>=A0</div><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>Is this just undefined?</div></blockquote><div><br></div><div>no<br></=
div><div>=A0</div><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>Is=
 it the same behavior as setjmp/longjmp exhibit? (I think setjmp/longjmp wo=
uld be undefined in this case according to 18.10p4.)</div>
</blockquote><div><br></div><div>I don&#39;t use setjmp/longjmp.<br><br></d=
iv><div>=A0</div><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><br=
></div>
<div>In general, is checkpoint()/rollback() equivalent to setjmp and longjm=
p within the context of the coroutine, i.e. it only changes execution posit=
ion, not values? Or would values be changed in some way?</div></blockquote>
<div><br></div><div>code between the checkpoint and the last instruction in=
 the coroutine-fn is unwound if a rollback is done to the checkpoint (in yo=
ur case std::vector&lt; int &gt; gets destructed).<br></div><div>if the cor=
outine is then resumed it executes the instructions following after the che=
cpoint - in your case std::vector&lt; int &gt; is constructed.<br>
</div><div><br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div><br></div><div>These seem to me to be non-trivial issues that would onl=
y muddle the proposal you have now. And I see no reason why checkpointing c=
ouldn&#39;t be added later in a separate proposal.</div>
</blockquote><div><br></div><div>I&#39;ve already some code - a proof of co=
ncept - which is working. As Beman Daws already told I&#39;ll add this late=
r to the proposal (I think if it is working in boost.coroutine).<br><br>
</div><div>Oliver<br></div><div>=A0</div></div><br></div></div>

<p></p>

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

--e89a8ff1c9b8154f6c04d9dad43d--

.

------=_Part_1745_13188087.1365433153951
Content-Type: text/plain; charset=ISO-8859-1


On Friday, March 22, 2013 10:16:39 AM UTC+1, Oliver Kowalke wrote:
>
> I'm currently working to support checkpointing of coroutines - I think it
> would be useful too?!
> Should I add it to the proposal?
>

No, absolutely not. While checkpointing might be useful, I think it is far
too complicated and dangerous to be added to the initial proposal. Adding
checkpointing means you have to define what this means:

checkpoint cp;
std::coroutine< int() > c(
   [&](std::coroutine< void( int) > & c) {
      int i = 0;
      cp = c.checkpoint(); // coroutine checkpoint
      std::vector<int> v(5, 5);
      while ( true) {
         c( ++i);
});

c().get();

c.rollback( cp);

What happens to the vector on rollback? Is it destroyed and reconstructed?
Is its initialization skipped the second time around? Is this just
undefined? Is it the same behavior as setjmp/longjmp exhibit? (I think
setjmp/longjmp would be undefined in this case according to 18.10p4.)

In general, is checkpoint()/rollback() equivalent to setjmp and longjmp
within the context of the coroutine, i.e. it only changes execution
position, not values? Or would values be changed in some way?

These seem to me to be non-trivial issues that would only muddle the
proposal you have now. And I see no reason why checkpointing couldn't be
added later in a separate proposal.

Sebastian

--

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



------=_Part_1745_13188087.1365433153951
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br>On Friday, March 22, 2013 10:16:39 AM UTC+1, Oliver Kowalke wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">I'm currently working to support ch=
eckpointing of coroutines - I think it would be useful too?!<br>Should I ad=
d it to the proposal?<br></blockquote><div><br></div><div>No, absolutely no=
t. While checkpointing might be useful, I think it is far too complicated a=
nd dangerous to be added to the initial proposal. Adding checkpointing mean=
s you have to define what this means:</div><div><br></div><div>checkpoint c=
p;<br>std::coroutine&lt; int() &gt; c(<br>&nbsp;&nbsp; [&amp;](std::corouti=
ne&lt; void( int) &gt; &amp; c) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; int i =
=3D 0;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; cp =3D c.checkpoint(); // coroutin=
e checkpoint<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; std::vector&lt;int&gt; v(5, =
5);<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while ( true) {<br>&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; c( ++i);<br>});<br><br>c().get();<br><br>c.r=
ollback( cp);<br><br></div><div>What happens to the vector on rollback? Is =
it destroyed and reconstructed? Is its initialization skipped the second ti=
me around? Is this just undefined? Is it the same behavior as setjmp/longjm=
p exhibit? (I think setjmp/longjmp would be undefined in this case accordin=
g to 18.10p4.)</div><div><br></div><div>In general, is checkpoint()/rollbac=
k() equivalent to setjmp and longjmp within the context of the coroutine, i=
..e. it only changes execution position, not values? Or would values be chan=
ged in some way?</div><div><br></div><div>These seem to me to be non-trivia=
l issues that would only muddle the proposal you have now. And I see no rea=
son why checkpointing couldn't be added later in a separate proposal.</div>=
<div><br></div><div>Sebastian</div><div><br></div>

<p></p>

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

------=_Part_1745_13188087.1365433153951--

.