------=_Part_244_1558094271.1520715351648
Content-Type: multipart/alternative;
 boundary="----=_Part_245_1546627762.1520715351648"

------=_Part_245_1546627762.1520715351648
Content-Type: text/plain; charset="UTF-8"

I have a few questions about the library fibers proposal, P0876.

* Fibers are bound to the thread that initially created them; they cannot
be resumed in any other thread. Is this restriction necessary? What are the
performance costs for allowing them to be used in any thread? Is that
perhaps an aspect that can be decided on at `fiber` creation time?

* Is it possible to add a way to transfer ownership of a suspended fiber to
another thread? Obvious that depends on exactly why fibers are bound to
their creating thread.

* Is it possible to have a way to ask if a fiber is associated with a given
thread?

* Would it be possible to create a thread with a fiber? I'm not saying that
you should be able to create a thread and pass it an existing `std::fiber`.
I'm asking if it is reasonable for `std::thread` to have some of the fiber
constructors, so that we could pass stack allocators that can control the
size of stack they get.

* Would it be reasonable to have an API that can take a terminated fiber
and give it a new entry-function? The purpose of this would be to avoid
having to deallocate a stack and then immediately reallocate it. You would
be able to keep a number of fibers lying around and pull one out when you
want to execute a new task. I know that `resume_with` can work like this to
some extent, but invoking an unwind operation on the stack will unwind past
where `resume_with` started. This way, there is nothing "past" the entry
function; a refurbished fiber is functionally identical to a fiber that was
previously used.

* It's not clear to me exactly how `resume_with` works, with regard to the
underlying parts of the stack. That is, is there a way to use `resume_with`
to execute the given function, then immediately go back and resume the
execution of whatever was below it on the fiber's stack? Or is
`resume_with` completely incapable of interacting with the previous stuff
on the stack?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ea3e8a64-6363-4460-9ce0-1202768be57d%40isocpp.org.

------=_Part_245_1546627762.1520715351648
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I have a few questions about the library fibers proposal, =
P0876.<br><br>* Fibers are bound to the thread that initially created them;=
 they cannot be resumed in any other thread. Is this restriction necessary?=
 What are the performance costs for allowing them to be used in any thread?=
 Is that perhaps an aspect that can be decided on at `fiber` creation time?=
<br><br>* Is it possible to add a way to transfer ownership of a suspended =
fiber to another thread? Obvious that depends on exactly why fibers are bou=
nd to their creating thread.<br><br>* Is it possible to have a way to ask i=
f a fiber is associated with a given thread?<br><br>* Would it be possible =
to create a thread with a fiber? I&#39;m not saying that you should be able=
 to create a thread and pass it an existing `std::fiber`. I&#39;m asking if=
 it is reasonable for `std::thread` to have some of the fiber constructors,=
 so that we could pass stack allocators that can control the size of stack =
they get.<br><br>* Would it be reasonable to have an API that can take a te=
rminated fiber and give it a new entry-function? The purpose of this would =
be to avoid having to deallocate a stack and then immediately reallocate it=
.. You would be able to keep a number of fibers lying around and pull one ou=
t when you want to execute a new task. I know that `resume_with` can work l=
ike this to some extent, but invoking an unwind operation on the stack will=
 unwind past where `resume_with` started. This way, there is nothing &quot;=
past&quot; the entry function; a refurbished fiber is functionally identica=
l to a fiber that was previously used.<br><br>* It&#39;s not clear to me ex=
actly how `resume_with` works, with regard to the underlying parts of the s=
tack. That is, is there a way to use `resume_with` to execute the given fun=
ction, then immediately go back and resume the execution of whatever was be=
low it on the fiber&#39;s stack? Or is `resume_with` completely incapable o=
f interacting with the previous stuff on the stack?<br><br><br></div>

<p></p>

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

------=_Part_245_1546627762.1520715351648--

------=_Part_244_1558094271.1520715351648--

.

--089e0825243c8c458e056715b838
Content-Type: text/plain; charset="UTF-8"

2018-03-10 21:55 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:

> I have a few questions about the library fibers proposal, P0876.
>
> * Fibers are bound to the thread that initially created them; they cannot
> be resumed in any other thread. Is this restriction necessary?
>

This restriction was requested by SG1 at the last C++ meeting (because of
the TLS problem, which is not fiber specific).


> What are the performance costs for allowing them to be used in any thread?
>

none, fibers are unaware of the thread


> Is that perhaps an aspect that can be decided on at `fiber` creation time?
>

yes, infact fibers are stacks. you can create a fiber in thread A and
start/resume it at thread B.


> * Is it possible to add a way to transfer ownership of a suspended fiber
> to another thread? Obvious that depends on exactly why fibers are bound to
> their creating thread.
>

fibers are not bound to a thread ... suspended fibers can be migrated
between threads (but see TLS problem above)


> * Is it possible to have a way to ask if a fiber is associated with a
> given thread?
>

fibers are not 'associated' with a thread but run in a context of a thread
(scheduled inside the thread).
fibers are suspend- and resumable stacks. a thread starts with a stack too
(the stack that was assigned by the OS) and can be suspended and resumed.
in other words, a thread is a container running one (e.g. the stack created
by the OS) or multiple fibers


> * Would it be possible to create a thread with a fiber?
>

a thread already runs at least one fiber (== one stack)


> I'm not saying that you should be able to create a thread and pass it an
> existing `std::fiber`. I'm asking if it is reasonable for `std::thread` to
> have some of the fiber constructors, so that we could pass stack allocators
> that can control the size of stack they get.
>

p0320r0 suggestes std::thread::attributes controling the stack size and
some other stuff


> * Would it be reasonable to have an API that can take a terminated fiber
> and give it a new entry-function? The purpose of this would be to avoid
> having to deallocate a stack and then immediately reallocate it.
>

allocating and reallocating is done by the stack allocator ... if you want
to resuse stacks ismply create a stack allocator that caches stacks


> You would be able to keep a number of fibers lying around and pull one out
> when you want to execute a new task.
>

what about taking a std::function from a queue


> * It's not clear to me exactly how `resume_with` works, with regard to the
> underlying parts of the stack. That is, is there a way to use `resume_with`
> to execute the given function, then immediately go back and resume the
> execution of whatever was below it on the fiber's stack?
>

yes, the proposal contains an example describing how resume_with() works

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19M2fH16RQuyJJugy%3DBDjSu6RzwULLURRuk-szRbbBdFg%40mail.gmail.com.

--089e0825243c8c458e056715b838
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2018-03-10 21:55 GMT+01:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"lt=
r">I have a few questions about the library fibers proposal, P0876.<br><br>=
* Fibers are bound to the thread that initially created them; they cannot b=
e resumed in any other thread. Is this restriction necessary?</div></blockq=
uote><div><br></div><div>This restriction was requested by SG1 at the last =
C++ meeting (because of the TLS problem, which is not fiber specific).<br><=
/div><div>=C2=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"><di=
v dir=3D"ltr">What are the performance costs for allowing them to be used i=
n any thread?</div></blockquote><div><br></div><div>none, fibers are unawar=
e of the thread<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div dir=3D"ltr"> Is that perhaps an aspect that can be decided on at=
 `fiber` creation time?<br></div></blockquote><div><br></div><div>yes, infa=
ct fibers are stacks. you can create a fiber in thread A and start/resume i=
t at thread B.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr">* Is it possible to add a way to transfer =
ownership of a suspended fiber to another thread? Obvious that depends on e=
xactly why fibers are bound to their creating thread.<br></div></blockquote=
><div><br></div><div>fibers are not bound to a thread ... suspended fibers =
can be migrated between threads (but see TLS problem above)<br></div><div>=
=C2=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 dir=3D"l=
tr">* Is it possible to have a way to ask if a fiber is associated with a g=
iven thread?<br></div></blockquote><div><br></div><div>fibers are not &#39;=
associated&#39; with a thread but run in a context of a thread (scheduled i=
nside the thread).<br>fibers are suspend- and resumable stacks. a thread st=
arts with a stack too (the stack that was assigned by the OS) and can be su=
spended and resumed.<br></div><div>in other words, a thread is a container =
running one (e.g. the stack created by the OS) or multiple fibers<br></div>=
<div>=C2=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 dir=
=3D"ltr">* Would it be possible to create a thread with a fiber?</div></blo=
ckquote><div><br></div><div>a thread already runs at least one fiber (=3D=
=3D one stack)<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"> I&#39;m not saying that you should be abl=
e to create a thread and pass it an existing `std::fiber`. I&#39;m asking i=
f it is reasonable for `std::thread` to have some of the fiber constructors=
, so that we could pass stack allocators that can control the size of stack=
 they get.<br></div></blockquote><div><br></div><div>p0320r0 suggestes std:=
:thread::attributes controling the stack size and some other stuff<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
>* Would it be reasonable to have an API that can take a terminated fiber a=
nd give it a new entry-function? The purpose of this would be to avoid havi=
ng to deallocate a stack and then immediately reallocate it. </div></blockq=
uote><div><br></div><div>allocating and reallocating is done by the stack a=
llocator ... if you want to resuse stacks ismply create a stack allocator t=
hat caches stacks<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr">You would be able to keep a number of f=
ibers lying around and pull one out when you want to execute a new task.<br=
></div></blockquote><div><br></div><div>what about taking a std::function f=
rom a queue<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr">* It&#39;s not clear to me exactly how `resum=
e_with` works, with regard to the underlying parts of the stack. That is, i=
s there a way to use `resume_with` to execute the given function, then imme=
diately go back and resume the execution of whatever was below it on the fi=
ber&#39;s stack? </div></blockquote><div><br></div><div>yes, the proposal c=
ontains an example describing how resume_with() works<br></div></div><br></=
div></div>

<p></p>

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

--089e0825243c8c458e056715b838--

.

------=_Part_10014_1319253806.1520732392719
Content-Type: multipart/alternative;
 boundary="----=_Part_10015_1706840726.1520732392719"

------=_Part_10015_1706840726.1520732392719
Content-Type: text/plain; charset="UTF-8"

On Saturday, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Kowalke wrote:
>
>
>
> 2018-03-10 21:55 GMT+01:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> I have a few questions about the library fibers proposal, P0876.
>>
>> * Fibers are bound to the thread that initially created them; they cannot
>> be resumed in any other thread. Is this restriction necessary?
>>
>
> This restriction was requested by SG1 at the last C++ meeting (because of
> the TLS problem, which is not fiber specific).
>

That answer renders all of my subsequent thread-limited-fiber questions
moot, since they were all written under the assumption that this was a
technical limitation.

But that brings up the question: why impose this limitation?

To my knowledge, there is nothing in the Coroutines TS that prevents a
coroutine function from being executed on a different thread at different
stages of its execution. Any thread-local storage issues would be just as
apparent for the Coroutines TS as it would be for fibers.

Indeed, this limitation makes it effectively impossible to do something as
simple as pass a fiber (that is, a lambda which resumes a `std::fiber`) to
a networking callback, or any `future.then` or anything of the sort. Oh,
the callback function could create a fiber in the callback, but the
callback itself could not *resume* an existing fiber. Any kind of
suspend-up style system would be incompatible with fibers that cannot be
executed from arbitrary threads.

So why are fibers limited in this way when coroutine functions are not?

* Would it be possible to create a thread with a fiber?
>>
>
> a thread already runs at least one fiber (== one stack)
>
>
>> I'm not saying that you should be able to create a thread and pass it an
>> existing `std::fiber`. I'm asking if it is reasonable for `std::thread` to
>> have some of the fiber constructors, so that we could pass stack allocators
>> that can control the size of stack they get.
>>
>
> p0320r0 suggestes std::thread::attributes controling the stack size and
> some other stuff
>

Well, my hope would be that we wouldn't have two distinct APIs for this
kind of thing. If threads have fibers, then it seems reasonable to be able
to construct a thread using the fiber system's techniques. If I have a
stack allocator, it'd be nice to be able to use it with `std::thread` just
as well as `std::fiber`.

* Would it be reasonable to have an API that can take a terminated fiber
>> and give it a new entry-function? The purpose of this would be to avoid
>> having to deallocate a stack and then immediately reallocate it.
>>
>
> allocating and reallocating is done by the stack allocator ... if you want
> to resuse stacks ismply create a stack allocator that caches stacks
>

Outside of allocating stacks, is the cost of constructing a new fiber
pretty marginal?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e36a3e2e-9981-4a93-ba62-29489044f1cf%40isocpp.org.

------=_Part_10015_1706840726.1520732392719
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Ko=
walke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br><div><br><div class=3D"gmail_quote">2018-03-10 21:55 GMT+01:00 Nicol Bol=
as <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"bIUO0GNRAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">jmck...@gmail.com</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">I have a few questions ab=
out the library fibers proposal, P0876.<br><br>* Fibers are bound to the th=
read that initially created them; they cannot be resumed in any other threa=
d. Is this restriction necessary?</div></blockquote><div><br></div><div>Thi=
s restriction was requested by SG1 at the last C++ meeting (because of the =
TLS problem, which is not fiber specific).<br></div></div></div></div></blo=
ckquote><div><br>That answer renders all of my subsequent thread-limited-fi=
ber questions moot, since they were all written under the assumption that t=
his was a technical limitation.<br><br>But that brings up the question: why=
 impose this limitation?<br><br>To my knowledge, there is nothing in the Co=
routines TS that prevents a coroutine function from being executed on a dif=
ferent thread at different stages of its execution. Any thread-local storag=
e issues would be just as apparent for the Coroutines TS as it would be for=
 fibers.<br><br>Indeed, this limitation makes it effectively impossible to =
do something as simple as pass a fiber (that is, a lambda which resumes a `=
std::fiber`) to a networking callback, or any `future.then` or anything of =
the sort. Oh, the callback function could create a fiber in the callback, b=
ut the callback itself could not <i>resume</i> an existing fiber. Any kind =
of suspend-up style system would be incompatible with fibers that cannot be=
 executed from arbitrary threads.<br><br>So why are fibers limited in this =
way when coroutine functions are not?<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=
</div><div></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 dir=
=3D"ltr">* Would it be possible to create a thread with a fiber?</div></blo=
ckquote><div><br></div><div>a thread already runs at least one fiber (=3D=
=3D one stack)<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"> I&#39;m not saying that you should be abl=
e to create a thread and pass it an existing `std::fiber`. I&#39;m asking i=
f it is reasonable for `std::thread` to have some of the fiber constructors=
, so that we could pass stack allocators that can control the size of stack=
 they get.<br></div></blockquote><div><br></div><div>p0320r0 suggestes std:=
:thread::attributes controling the stack size and some other stuff<br></div=
></div></div></div></blockquote><div><br>Well, my hope would be that we wou=
ldn&#39;t have two distinct APIs for this kind of thing. If threads have fi=
bers, then it seems reasonable to be able to construct a thread using the f=
iber system&#39;s techniques. If I have a stack allocator, it&#39;d be nice=
 to be able to use it with `std::thread` just as well as `std::fiber`.<br><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"><div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr">* Would it be reasonable to have an API that=
 can take a terminated fiber and give it a new entry-function? The purpose =
of this would be to avoid having to deallocate a stack and then immediately=
 reallocate it. </div></blockquote><div><br></div><div>allocating and reall=
ocating is done by the stack allocator ... if you want to resuse stacks ism=
ply create a stack allocator that caches stacks<br></div></div></div></div>=
</blockquote><div><br>Outside of allocating stacks, is the cost of construc=
ting a new fiber pretty marginal?</div><br></div>

<p></p>

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

------=_Part_10015_1706840726.1520732392719--

------=_Part_10014_1319253806.1520732392719--

.

------=_Part_9835_1870445691.1520733348987
Content-Type: multipart/alternative;
 boundary="----=_Part_9836_113226171.1520733348988"

------=_Part_9836_113226171.1520733348988
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Kowalke wrote:
>
> 2018-03-10 21:55 GMT+01:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
>
>> * It's not clear to me exactly how `resume_with` works, with regard to=
=20
>> the underlying parts of the stack. That is, is there a way to use=20
>> `resume_with` to execute the given function, then immediately go back an=
d=20
>> resume the execution of whatever was below it on the fiber's stack?=20
>>
>
> yes, the proposal contains an example describing how resume_with() works
>
>
One question about this. I see that the return value from an injected=20
function is passed back to the previously executing call to=20
`resume/resume_with` on the underlying call stack. But... what happens if=
=20
there *is no* underlying call stack yet. That is, you have a fresh=20
`std::fiber` which has never been `resume`d, and you call `resume_with` on=
=20
it.

My guess is that the return value will be passed as the *parameter* to the=
=20
fiber's entry function. But I don't think your current proposal says that.=
=20
Or at least, the definition of `resume_with` doesn't seem to acknowledge=20
that possibility.

Oh, and one other thing. The proposal says this:

When calling `resume()`, it is conventional to replace the=20
> newly-invalidated instance =E2=80=93 the instance on which `resume()` was=
 called =E2=80=93=20
> with the new instance returned by that `resume()` call. This helps to avo=
id=20
> inadvertent calls to `resume()` on the old, invalidated instance.
>

That sounds like a good convention. So maybe there should be a couple of=20
global helper functions to help people adhere to it:

void resume(std::fiber &&f) {f =3D std::move(f).resume();}

template<typename Fn>
void resume_with(std::fiber &&f, Fn &&fn) {f =3D std::move(f).resume_with(s=
td
::forward<Fn>(fn));}

These could be member functions (with the names `resume_inplace` and=20
`resume_with_inplace`) instead of free functions.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9b3171e2-70c4-4cc6-8fb6-5e180b28eb94%40isocpp.or=
g.

------=_Part_9836_113226171.1520733348988
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Ko=
walke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote">2018-03-10 21:55 GMT+01:00 Nicol Bolas <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"bIUO0GNRAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">jmck...@gmail.com</a>&gt;</span>:<br><div></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">* It&#39;s not clear to=
 me exactly how `resume_with` works, with regard to the underlying parts of=
 the stack. That is, is there a way to use `resume_with` to execute the giv=
en function, then immediately go back and resume the execution of whatever =
was below it on the fiber&#39;s stack? </div></blockquote><div><br></div><d=
iv>yes, the proposal contains an example describing how resume_with() works=
<br></div></div><br></div></div></blockquote><div><br>One question about th=
is. I see that the return value from an injected function is passed back to=
 the previously executing call to `resume/resume_with` on the underlying ca=
ll stack. But... what happens if there <i>is no</i> underlying call stack y=
et. That is, you have a fresh `std::fiber` which has never been `resume`d, =
and you call `resume_with` on it.<br><br>My guess is that the return value =
will be passed as the <i>parameter</i> to the fiber&#39;s entry function. B=
ut I don&#39;t think your current proposal says that. Or at least, the defi=
nition of `resume_with` doesn&#39;t seem to acknowledge that possibility.<b=
r><br>Oh, and one other thing. The proposal says this:<br><br><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;">When calling `resume()`, it is=
 conventional to replace the newly-invalidated instance =E2=80=93 the insta=
nce on which `resume()` was called =E2=80=93 with the new instance returned=
 by that `resume()` call. This helps to avoid inadvertent calls to `resume(=
)` on the old, invalidated instance.<br></blockquote><br>That sounds like a=
 good convention. So maybe there should be a couple of global helper functi=
ons to help people adhere to it:<br><br><div style=3D"background-color: rgb=
(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; bor=
der-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> resume</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
fiber </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp=
;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">f </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">move</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">).</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">resume</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">();}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">template</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Fn</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
void</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> resum=
e_with</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">fiber </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Fn</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f=
n</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">f </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">move</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">f</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">).</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">resume_with</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">forward</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Fn</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&gt;(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">fn</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">));}</span></div></code></div><br>These could be member functions (with =
the names `resume_inplace` and `resume_with_inplace`) instead of free funct=
ions.<br></div></div>

<p></p>

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

------=_Part_9836_113226171.1520733348988--

------=_Part_9835_1870445691.1520733348987--

.

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

> To my knowledge, there is nothing in the Coroutines TS that prevents a
coroutine function from being executed on a different thread at different
stages of its execution.

One reason to argue for the difference would be that the coroutines TS is
just a low-level primitive. It tells you nothing beyond a set of function
calls and a state machine transformation. We would very much want to
enforce this requirement for most coroutine code in practice, but in the
library infrastructure, and we have the opportunity to enforce this
requirement in the library we provide in the standard. You can pass an
arbitrary coroutine that completed on an arbitrary thread to another
coroutine, and the type system can catch that fact and ensure that awaiting
on it does not cause the current coroutine to transition between threads.

Coroutines as defined do not work without the library infrastructure that
you have to write. The risk with this proposal is that you really can just
resume it from anywhere and suspend that caller. The fiber alone does
magical things to your current stack.

There is no safety around the basic primitive. As a result, the feeling in
the room was that it is better to start from the conservative position and
then relax it later once we fully understand any issues that may come up.
It's still an open question whether we want to specify library
infrastructure on top of this primitive, or only to specify fiber.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJH_FNVdkf5SA85KKYRL0TyNENXD_%3De%3D%3D9BrK8NPPbnUL8Borg%40mail.gmail.com.

--001a11c14658cd1624056719e6c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-size:12.800000190734863px">&gt; To my =
knowledge, there is nothing in the Coroutines TS that prevents a coroutine =
function from being executed on a different thread at different stages of i=
ts execution.=C2=A0</span><br><div class=3D"gmail_extra"><br></div><div cla=
ss=3D"gmail_extra">One reason to argue for the difference would be that the=
 coroutines TS is just a low-level primitive. It tells you nothing beyond a=
 set of function calls and a state machine transformation. We would very mu=
ch want to enforce this requirement for most coroutine code in practice, bu=
t in the library infrastructure, and we have the opportunity to enforce thi=
s requirement in the library we provide in the standard. You can pass an ar=
bitrary coroutine that completed on an arbitrary thread to another coroutin=
e, and the type system can catch that fact and ensure that awaiting on it d=
oes not cause the current coroutine to transition between threads.</div><di=
v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Coroutines as =
defined do not work without the library infrastructure that you have to wri=
te. The risk with this proposal is that you really can just resume it from =
anywhere and suspend that caller. The fiber alone does magical things to yo=
ur current stack.</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">There is no safety around the basic primitive. As a result, the=
 feeling in the room was that it is better to start from the conservative p=
osition and then relax it later once we fully understand any issues that ma=
y come up. It&#39;s still an open question whether we want to specify libra=
ry infrastructure on top of this primitive, or only to specify fiber.<br></=
div></div>

<p></p>

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

--001a11c14658cd1624056719e6c1--

.

------=_Part_3430_1414564018.1520751663313
Content-Type: multipart/alternative;
 boundary="----=_Part_3431_2047835878.1520751663313"

------=_Part_3431_2047835878.1520751663313
Content-Type: text/plain; charset="UTF-8"

On Saturday, March 10, 2018 at 9:37:10 PM UTC-5, Lee Howes wrote:
>
> > To my knowledge, there is nothing in the Coroutines TS that prevents a
> coroutine function from being executed on a different thread at different
> stages of its execution.
>
> One reason to argue for the difference would be that the coroutines TS is
> just a low-level primitive. It tells you nothing beyond a set of function
> calls and a state machine transformation. We would very much want to
> enforce this requirement for most coroutine code in practice,
>

I may be wrong here, but as I recall, the Networking TS makes no promises
that callbacks will be executed on the same thread that registered the
callback. The current `experimental::future::then` makes no promises about
which thread the continuation gets executed on. And so forth. Which means
that if "we" wanted to enforce this on Coroutines, it would be impossible
to use them on these interfaces.

I do not see how suspend-up continuations are useful in an environment
where you can only be continued in your current thread. If that's what
people wanted, they'd just use a message passing system to let them know
when the data was available so that they could finish processing it.

but in the library infrastructure, and we have the opportunity to enforce
> this requirement in the library we provide in the standard.
>

Declaring something to be UB is not really what I would call "enforcement".
Especially since, because there's no *technical* restriction in play,
pretty much every implementation will allow it to work as expected.

The situation this will create is that people won't know about the
restriction. They'll expect to be able to use fibers wherever they want, in
any thread they want. And yet there's a piece of paper out there saying
that their code is wrong. Which makes this just one more place in the
standard where "what the standard says" and "what real implementations
actually do" diverge.

That's not something C++ really needs *more* of.

I don't mean to make light of the thread-local storage issues. I understand
the issue that code (hidden from external view) which would normally not be
able to become disassociated from a thread now can become disassociated.
But if I can't do anything as simple as applying a fiber to a future's
`.then` method, then the fear of TLS problems is making the overall feature
a lot less useful.

You can pass an arbitrary coroutine that completed on an arbitrary thread
> to another coroutine, and the type system can catch that fact and ensure
> that awaiting on it does not cause the current coroutine to transition
> between threads.
>

> Coroutines as defined do not work without the library infrastructure that
> you have to write.
>

Can you point to a proposed or even suggested library infrastructure that
enforces restrictions of this sort? P0055 outlines a way to make Coroutines
work with Networking, as does P0162. It is my understanding that none of
them outline the restriction that a continuation given to their systems
will certainly and unquestionably be executed within the thread that
provided that continuation.

The risk with this proposal is that you really can just resume it from
> anywhere and suspend that caller. The fiber alone does magical things to
> your current stack.
>
> There is no safety around the basic primitive. As a result, the feeling in
> the room was that it is better to start from the conservative position and
> then relax it later once we fully understand any issues that may come up.
>

I'm of the opinion that a restriction on a feature, especially an
*unenforced* one like this, should not be imposed unless there is certain
knowledge of a genuine problem that cannot be resolved in another way.
Because doing this massively limits the usefulness of this feature.

A more realistic position would be to say that the thread-fiber, the fiber
created for each thread, cannot be resumed on anything other than its
originating thread. Subsidiary fibers are far less likely to have
thread-specific code in them. And its far less likely that the user will
accidentally resume a thread's fiber in another thread. It can certainly
still happen of course; since each halted fiber is uniquely owned by some
other fiber, it is possible for a subsidiary fiber to own the thread fiber
and carry that ownership with them to some other thread.

It's still an open question whether we want to specify library
> infrastructure on top of this primitive, or only to specify fiber.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0d038a29-a2d8-4761-837b-be8ff915314c%40isocpp.org.

------=_Part_3431_2047835878.1520751663313
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, March 10, 2018 at 9:37:10 PM UTC-5, Lee Howes=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><span =
style=3D"font-size:12.800000190734863px">&gt; To my knowledge, there is not=
hing in the Coroutines TS that prevents a coroutine function from being exe=
cuted on a different thread at different stages of its execution.=C2=A0</sp=
an><br><div><br></div><div>One reason to argue for the difference would be =
that the coroutines TS is just a low-level primitive. It tells you nothing =
beyond a set of function calls and a state machine transformation. We would=
 very much want to enforce this requirement for most coroutine code in prac=
tice,</div></div></blockquote><div><br>I may be wrong here, but as I recall=
, the Networking TS makes no promises that callbacks will be executed on th=
e same thread that registered the callback. The current `experimental::futu=
re::then` makes no promises about which thread the continuation gets execut=
ed on. And so forth. Which means that if &quot;we&quot; wanted to enforce t=
his on Coroutines, it would be impossible to use them on these interfaces.<=
br><br>I do not see how suspend-up continuations are useful in an environme=
nt where you can only be continued in your current thread. If that&#39;s wh=
at people wanted, they&#39;d just use a message passing system to let them =
know when the data was available so that they could finish processing it.<b=
r><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>but in the library infrastructure, and we have the opportunity to enfor=
ce this requirement in the library we provide in the standard.</div></div><=
/blockquote><div><br>Declaring something to be UB is not really what I woul=
d call &quot;enforcement&quot;. Especially since, because there&#39;s no <i=
>technical</i> restriction in play, pretty much every implementation will a=
llow it to work as expected.<br><br>The situation this will create is that =
people won&#39;t know about the restriction. They&#39;ll expect to be able =
to use fibers wherever they want, in any thread they want. And yet there&#3=
9;s a piece of paper out there saying that their code is wrong. Which makes=
 this just one more place in the standard where &quot;what the standard say=
s&quot; and &quot;what real implementations actually do&quot; diverge.<br><=
br>That&#39;s not something C++ really needs <i>more</i> of.<br><br>I don&#=
39;t mean to make light of the thread-local storage issues. I understand th=
e issue that code (hidden from external view) which would normally not be a=
ble to become disassociated from a thread now can become disassociated. But=
 if I can&#39;t do anything as simple as applying a fiber to a future&#39;s=
 `.then` method, then the fear of TLS problems is making the overall featur=
e a lot less useful.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>You can pass an arbitrary coroutine that comple=
ted on an arbitrary thread to another coroutine, and the type system can ca=
tch that fact and ensure that awaiting on it does not cause the current cor=
outine to transition between threads.</div></div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px s=
olid rgb(204, 204, 204); padding-left: 1ex;"><div><br></div></blockquote><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div=
>Coroutines as defined do not work without the library infrastructure that =
you have to write.</div></div></blockquote><div><br>Can you point to a prop=
osed or even suggested library infrastructure that enforces restrictions of=
 this sort? P0055 outlines a way to make Coroutines work with Networking, a=
s does P0162. It is my understanding that none of them outline the restrict=
ion that a continuation given to their systems will certainly and unquestio=
nably be executed within the thread that provided that continuation.<br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>T=
he risk with this proposal is that you really can just resume it from anywh=
ere and suspend that caller. The fiber alone does magical things to your cu=
rrent stack.</div><div><br></div><div>There is no safety around the basic p=
rimitive. As a result, the feeling in the room was that it is better to sta=
rt from the conservative position and then relax it later once we fully und=
erstand any issues that may come up.</div></div></blockquote><div>=C2=A0</d=
iv><div>I&#39;m of the opinion that a restriction on a feature, especially =
an <i>unenforced</i> one like this, should not be imposed unless there is c=
ertain knowledge of a genuine problem that cannot be resolved in another wa=
y. Because doing this massively limits the usefulness of this feature.<br><=
br>A more realistic position would be to say that the thread-fiber, the fib=
er created for each thread, cannot be resumed on anything other than its or=
iginating thread. Subsidiary fibers are far less likely to have thread-spec=
ific code in them. And its far less likely that the user will accidentally =
resume a thread&#39;s fiber in another thread. It can certainly still happe=
n of course; since each halted fiber is uniquely owned by some other fiber,=
 it is possible for a subsidiary fiber to own the thread fiber and carry th=
at ownership with them to some other thread.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It&#39;s still an open qu=
estion whether we want to specify library infrastructure on top of this pri=
mitive, or only to specify fiber.<br></div></div>
</blockquote></div>

<p></p>

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

------=_Part_3431_2047835878.1520751663313--

------=_Part_3430_1414564018.1520751663313--

.

--94eb2c142322f5784b0567240362
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2018-03-11 2:55 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:

> On Saturday, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Kowalke wrote:
>>
>> 2018-03-10 21:55 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
>>
>>> * It's not clear to me exactly how `resume_with` works, with regard to
>>> the underlying parts of the stack. That is, is there a way to use
>>> `resume_with` to execute the given function, then immediately go back a=
nd
>>> resume the execution of whatever was below it on the fiber's stack?
>>>
>>
>> yes, the proposal contains an example describing how resume_with() works
>>
>>
> One question about this. I see that the return value from an injected
> function is passed back to the previously executing call to
> `resume/resume_with` on the underlying call stack. But... what happens if
> there *is no* underlying call stack yet. That is, you have a fresh
> `std::fiber` which has never been `resume`d, and you call `resume_with` o=
n
> it.
>


It acts like starting the context the first time, executing the function
passed to resume_with() and then enters the function that was given the cto=
r
of fiber (should already be addressed in P0876).


> My guess is that the return value will be passed as the *parameter* to
> the fiber's entry function.
>

correct


> But I don't think your current proposal says that. Or at least, the
> definition of `resume_with` doesn't seem to acknowledge that possibility.
>

API section: notes for the constructor


>
> Oh, and one other thing. The proposal says this:
>
> When calling `resume()`, it is conventional to replace the
>> newly-invalidated instance =E2=80=93 the instance on which `resume()` wa=
s called =E2=80=93
>> with the new instance returned by that `resume()` call. This helps to av=
oid
>> inadvertent calls to `resume()` on the old, invalidated instance.
>>
>
> That sounds like a good convention. So maybe there should be a couple of
> global helper functions to help people adhere to it:
>
> void resume(std::fiber &&f) {f =3D std::move(f).resume();}
>
> template<typename Fn>
> void resume_with(std::fiber &&f, Fn &&fn) {f =3D std::move(f).resume_with=
(
> std::forward<Fn>(fn));}
>
> These could be member functions (with the names `resume_inplace` and
> `resume_with_inplace`) instead of free functions.
>

yes, sounds reasonable

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2Bwfc1-f1rsn3N_L5F95Xej202NQJBKWd1-aSFPq%3Dp4=
x0n5RmA%40mail.gmail.com.

--94eb2c142322f5784b0567240362
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2018-03-11 2:55 GMT+01:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"=
mailto:jmckesson@gmail.com" target=3D"_blank"><span class=3D"" style=3D"" i=
d=3D":1ud.13" tabindex=3D"-1">jmckesson</span>@gmail.com</a>&gt;</span>:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Saturd=
ay, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Kowalke wrote:</span><span c=
lass=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote">2018-03-10 21:55 GMT+01:00 Nicol Bolas <span dir=3D=
"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span>:<br><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">* It&=
#39;s not clear to me exactly how `resume_with` works, with regard to the u=
nderlying parts of the stack. That is, is there a way to use `resume_with` =
to execute the given function, then immediately go back and resume the exec=
ution of whatever was below it on the fiber&#39;s stack? </div></blockquote=
><div><br></div><div>yes, the proposal contains an example describing how r=
esume_with() works<br></div></div><br></div></div></blockquote></span><div>=
<br>One question about this. I see that the return value from an injected f=
unction is passed back to the previously executing call to `resume/resume_w=
ith` on the underlying call stack. But... what happens if there <i>is no</i=
> underlying call stack yet. That is, you have a fresh `std::fiber` which h=
as never been `resume`d, and you call `resume_with` on it.<br></div></div><=
/blockquote><div><br><br></div><div>It acts like starting the context the f=
irst time, executing the function passed to resume_with() and then enters t=
he function that was given the <span class=3D"" style=3D"" id=3D":1ud.14" t=
abindex=3D"-1">ctor</span> of <span class=3D"" style=3D"" id=3D":1ud.15" ta=
bindex=3D"-1">fiber</span> (should already be addressed in P0876).<br><div =
id=3D":1o8" style=3D"-moz-user-select: none;" class=3D"ajR" tabindex=3D"-1"=
><div>=C2=A0</div></div></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>My guess is that the return value will be passed as the <i>paramete=
r</i> to the fiber&#39;s entry function. </div></div></blockquote><div><br>=
</div><div>correct<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>But I don&#39;t think your current proposal says tha=
t. Or at least, the definition of `resume_with` doesn&#39;t seem to acknowl=
edge that possibility.<br></div></div></blockquote><div><br></div><div>API =
section: notes for the <span class=3D"" style=3D"" id=3D":1ud.16" tabindex=
=3D"-1">constructor</span><br></div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><br>Oh, and one other thing. The proposal sa=
ys this:<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">When call=
ing `resume()`, it is conventional to replace the newly-invalidated instanc=
e =E2=80=93 the instance on which `resume()` was called =E2=80=93 with the =
new instance returned by that `resume()` call. This helps to avoid inadvert=
ent calls to `resume()` on the old, invalidated instance.<br></blockquote><=
br>That sounds like a good convention. So maybe there should be a couple of=
 global helper functions to help people adhere to it:<br><br><div style=3D"=
background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-styl=
e:solid;border-width:1px" class=3D"m_7806156637129470091prettyprint"><code =
class=3D"m_7806156637129470091prettyprint"><div class=3D"m_7806156637129470=
091subprettyprint"><span style=3D"color:#008" class=3D"m_780615663712947009=
1styled-by-prettify">void</span><span style=3D"color:#000" class=3D"m_78061=
56637129470091styled-by-prettify"> resume</span><span style=3D"color:#660" =
class=3D"m_7806156637129470091styled-by-prettify">(</span><span style=3D"co=
lor:#000" class=3D"m_7806156637129470091styled-by-prettify">std</span><span=
 style=3D"color:#660" class=3D"m_7806156637129470091styled-by-prettify">::<=
/span><span style=3D"color:#000" class=3D"m_7806156637129470091styled-by-pr=
ettify">fiber </span><span style=3D"color:#660" class=3D"m_7806156637129470=
091styled-by-prettify">&amp;&amp;</span><span style=3D"color:#000" class=3D=
"m_7806156637129470091styled-by-prettify">f</span><span style=3D"color:#660=
" class=3D"m_7806156637129470091styled-by-prettify">)</span><span style=3D"=
color:#000" class=3D"m_7806156637129470091styled-by-prettify"> </span><span=
 style=3D"color:#660" class=3D"m_7806156637129470091styled-by-prettify">{</=
span><span style=3D"color:#000" class=3D"m_7806156637129470091styled-by-pre=
ttify">f </span><span style=3D"color:#660" class=3D"m_7806156637129470091st=
yled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_780615663=
7129470091styled-by-prettify"> std</span><span style=3D"color:#660" class=
=3D"m_7806156637129470091styled-by-prettify">::</span><span style=3D"color:=
#000" class=3D"m_7806156637129470091styled-by-prettify">move</span><span st=
yle=3D"color:#660" class=3D"m_7806156637129470091styled-by-prettify">(</spa=
n><span style=3D"color:#000" class=3D"m_7806156637129470091styled-by-pretti=
fy">f</span><span style=3D"color:#660" class=3D"m_7806156637129470091styled=
-by-prettify">).</span><span style=3D"color:#000" class=3D"m_78061566371294=
70091styled-by-prettify">resume</span><span style=3D"color:#660" class=3D"m=
_7806156637129470091styled-by-prettify">();}</span><span style=3D"color:#00=
0" class=3D"m_7806156637129470091styled-by-prettify"><br><br></span><span s=
tyle=3D"color:#008" class=3D"m_7806156637129470091styled-by-prettify">templ=
ate</span><span style=3D"color:#660" class=3D"m_7806156637129470091styled-b=
y-prettify">&lt;</span><span style=3D"color:#008" class=3D"m_78061566371294=
70091styled-by-prettify">typename</span><span style=3D"color:#000" class=3D=
"m_7806156637129470091styled-by-prettify"> </span><span style=3D"color:#606=
" class=3D"m_7806156637129470091styled-by-prettify">Fn</span><span style=3D=
"color:#660" class=3D"m_7806156637129470091styled-by-prettify">&gt;</span><=
span style=3D"color:#000" class=3D"m_7806156637129470091styled-by-prettify"=
><br></span><span style=3D"color:#008" class=3D"m_7806156637129470091styled=
-by-prettify">void</span><span style=3D"color:#000" class=3D"m_780615663712=
9470091styled-by-prettify"> resume_with</span><span style=3D"color:#660" cl=
ass=3D"m_7806156637129470091styled-by-prettify">(</span><span style=3D"colo=
r:#000" class=3D"m_7806156637129470091styled-by-prettify">std</span><span s=
tyle=3D"color:#660" class=3D"m_7806156637129470091styled-by-prettify">::</s=
pan><span style=3D"color:#000" class=3D"m_7806156637129470091styled-by-pret=
tify">fiber </span><span style=3D"color:#660" class=3D"m_780615663712947009=
1styled-by-prettify">&amp;&amp;</span><span style=3D"color:#000" class=3D"m=
_7806156637129470091styled-by-prettify">f</span><span style=3D"color:#660" =
class=3D"m_7806156637129470091styled-by-prettify">,</span><span style=3D"co=
lor:#000" class=3D"m_7806156637129470091styled-by-prettify"> </span><span s=
tyle=3D"color:#606" class=3D"m_7806156637129470091styled-by-prettify">Fn</s=
pan><span style=3D"color:#000" class=3D"m_7806156637129470091styled-by-pret=
tify"> </span><span style=3D"color:#660" class=3D"m_7806156637129470091styl=
ed-by-prettify">&amp;&amp;</span><span style=3D"color:#000" class=3D"m_7806=
156637129470091styled-by-prettify">fn</span><span style=3D"color:#660" clas=
s=3D"m_7806156637129470091styled-by-prettify">)</span><span style=3D"color:=
#000" class=3D"m_7806156637129470091styled-by-prettify"> </span><span style=
=3D"color:#660" class=3D"m_7806156637129470091styled-by-prettify">{</span><=
span style=3D"color:#000" class=3D"m_7806156637129470091styled-by-prettify"=
>f </span><span style=3D"color:#660" class=3D"m_7806156637129470091styled-b=
y-prettify">=3D</span><span style=3D"color:#000" class=3D"m_780615663712947=
0091styled-by-prettify"> std</span><span style=3D"color:#660" class=3D"m_78=
06156637129470091styled-by-prettify">::</span><span style=3D"color:#000" cl=
ass=3D"m_7806156637129470091styled-by-prettify">move</span><span style=3D"c=
olor:#660" class=3D"m_7806156637129470091styled-by-prettify">(</span><span =
style=3D"color:#000" class=3D"m_7806156637129470091styled-by-prettify">f</s=
pan><span style=3D"color:#660" class=3D"m_7806156637129470091styled-by-pret=
tify">).</span><span style=3D"color:#000" class=3D"m_7806156637129470091sty=
led-by-prettify">resume_with</span><span style=3D"color:#660" class=3D"m_78=
06156637129470091styled-by-prettify">(</span><span style=3D"color:#000" cla=
ss=3D"m_7806156637129470091styled-by-prettify">std</span><span style=3D"col=
or:#660" class=3D"m_7806156637129470091styled-by-prettify">::</span><span s=
tyle=3D"color:#000" class=3D"m_7806156637129470091styled-by-prettify"><wbr>=
forward</span><span style=3D"color:#660" class=3D"m_7806156637129470091styl=
ed-by-prettify">&lt;</span><span style=3D"color:#606" class=3D"m_7806156637=
129470091styled-by-prettify">Fn</span><span style=3D"color:#660" class=3D"m=
_7806156637129470091styled-by-prettify">&gt;(</span><span style=3D"color:#0=
00" class=3D"m_7806156637129470091styled-by-prettify">fn</span><span style=
=3D"color:#660" class=3D"m_7806156637129470091styled-by-prettify">));}</spa=
n></div></code></div><br>These could be member functions (with the names `r=
esume_inplace` and `resume_with_inplace`) instead of free functions.<br></d=
iv></div></blockquote></div><br></div><div class=3D"gmail_extra">yes, sound=
s reasonable<br></div></div>

<p></p>

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

--94eb2c142322f5784b0567240362--

.

------=_Part_11793_339716816.1520785253586
Content-Type: multipart/alternative;
 boundary="----=_Part_11794_1453448440.1520785253586"

------=_Part_11794_1453448440.1520785253586
Content-Type: text/plain; charset="UTF-8"

On Sunday, March 11, 2018 at 10:41:09 AM UTC-4, Oliver Kowalke wrote:
>
> 2018-03-11 2:55 GMT+01:00 Nicol Bolas <jmckesson@gmail.com <javascript:>>:
>
>> On Saturday, March 10, 2018 at 4:37:54 PM UTC-5, Oliver Kowalke wrote:
>>>
>>> 2018-03-10 21:55 GMT+01:00 Nicol Bolas <jmck...@gmail.com>:
>>>
>>>> * It's not clear to me exactly how `resume_with` works, with regard to
>>>> the underlying parts of the stack. That is, is there a way to use
>>>> `resume_with` to execute the given function, then immediately go back and
>>>> resume the execution of whatever was below it on the fiber's stack?
>>>>
>>>
>>> yes, the proposal contains an example describing how resume_with() works
>>>
>>>
>> One question about this. I see that the return value from an injected
>> function is passed back to the previously executing call to
>> `resume/resume_with` on the underlying call stack. But... what happens if
>> there *is no* underlying call stack yet. That is, you have a fresh
>> `std::fiber` which has never been `resume`d, and you call `resume_with` on
>> it.
>>
>
>
> It acts like starting the context the first time, executing the function
> passed to resume_with() and then enters the function that was given the
> ctor of fiber (should already be addressed in P0876).
>
>
>> My guess is that the return value will be passed as the *parameter* to
>> the fiber's entry function.
>>
>
> correct
>
>
>> But I don't think your current proposal says that. Or at least, the
>> definition of `resume_with` doesn't seem to acknowledge that possibility.
>>
>
> API section: notes for the constructor
>

Unless you've updated P0876, I don't see anything about this in the
constructor notes. Those notes are:

The entry-function fn is not immediately entered. The stack and any other
> necessary resources are created on construction, but fn is not entered
> until resume() or resume_with() is called.
>
> The entry-function fn passed to std::fiber will be passed a synthesized
> std::fiber instance representing the suspended caller of resume().
>
> The function fn passed to resume_with() will be passed a synthesized
> std::fiber instance representing the suspended caller of resume_with().
>

This says nothing about where the return value from the `fn` passed to
`resume_with` will go. And the second bullet point explicitly states that
the entry-function will *only* get the fiber representing the caller of
`resume`; what fiber it gets from `resume_with` is left unstated.

The second bullet point should probably read:

*The entry-function fn passed to std::fiber will be passed a synthesized
> std::fiber instance representing the suspended caller of resume() or the
> return value of an injected fn from a call to resume_with().*
>

Then, there's the definition in the notes section of `resume_with`, which
says nothing of this sort:

An injected function fn() must accept std::fiber&& and return std::fiber.
> The fiber instance returned by fn() is, in turn, used as the return value
> for the suspended function: resume() or resume_with().
>

That paragraph needs to be changed too. I'd say it should look like the
following:

*An injected function fn() must accept std::fiber&& and return std::fiber.
> The fiber instance returned by fn() is, in turn, used as the return value
> for the previously executed suspended function in the fiber: resume() or
> resume_with(). If there was no previously executed suspend function, then
> the return value will be passed as the parameter of the entry-function.*
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7a9a024-77c5-4b0a-b90f-7904f4774eea%40isocpp.org.

------=_Part_11794_1453448440.1520785253586
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, March 11, 2018 at 10:41:09 AM UTC-4, 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;"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote">2018-03-11 2:55 GMT+01:00 Nicol Bolas <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"35plYzqJAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javas=
cript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;"><span>jmckesson</span>@gmail.com</a>&gt;</span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><span>On Saturday, March 10, 2018 at 4:3=
7:54 PM UTC-5, Oliver Kowalke wrote:</span><span><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">2018-03-10 2=
1:55 GMT+01:00 Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck..=
..@gmail.com</a>&gt;</span>:<br><div></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr">* It&#39;s not clear to me exactly how `r=
esume_with` works, with regard to the underlying parts of the stack. That i=
s, is there a way to use `resume_with` to execute the given function, then =
immediately go back and resume the execution of whatever was below it on th=
e fiber&#39;s stack? </div></blockquote><div><br></div><div>yes, the propos=
al contains an example describing how resume_with() works<br></div></div><b=
r></div></div></blockquote></span><div><br>One question about this. I see t=
hat the return value from an injected function is passed back to the previo=
usly executing call to `resume/resume_with` on the underlying call stack. B=
ut... what happens if there <i>is no</i> underlying call stack yet. That is=
, you have a fresh `std::fiber` which has never been `resume`d, and you cal=
l `resume_with` on it.<br></div></div></blockquote><div><br><br></div><div>=
It acts like starting the context the first time, executing the function pa=
ssed to resume_with() and then enters the function that was given the <span=
>ctor</span> of <span>fiber</span> (should already be addressed in P0876).<=
br><div><div>=C2=A0</div></div></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>My guess is that the return value will be passed as the <i>p=
arameter</i> to the fiber&#39;s entry function. </div></div></blockquote><d=
iv><br></div><div>correct<br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>But I don&#39;t think your current proposal s=
ays that. Or at least, the definition of `resume_with` doesn&#39;t seem to =
acknowledge that possibility.<br></div></div></blockquote><div><br></div><d=
iv>API section: notes for the <span>constructor</span></div></div></div></d=
iv></blockquote><div><br>Unless you&#39;ve updated P0876, I don&#39;t see a=
nything about this in the constructor notes. Those notes are:<br><br><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;">The entry-function fn i=
s not immediately entered. The stack and any other necessary resources are =
created on construction, but fn is not entered until resume() or resume_wit=
h() is called.<br><br>The entry-function fn passed to std::fiber will be pa=
ssed a synthesized std::fiber instance representing the suspended caller of=
 resume().<br><br>The function fn passed to resume_with() will be passed a =
synthesized std::fiber instance representing the suspended caller of resume=
_with().<br></blockquote><br>This says nothing about where the return value=
 from the `fn` passed to `resume_with` will go. And the second bullet point=
 explicitly states that the entry-function will <i>only</i> get the fiber r=
epresenting the caller of `resume`; what fiber it gets from `resume_with` i=
s left unstated.<br><br>The second bullet point should probably read:<br><b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><i>The entry-fu=
nction fn passed to std::fiber will be passed a synthesized std::fiber inst=
ance representing the suspended caller of resume() or the return value of a=
n injected fn from a call to resume_with().</i><br></blockquote><br>Then, t=
here&#39;s the definition in the notes section of `resume_with`, which says=
 nothing of this sort:<br><br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;">An injected function fn() must accept std::fiber&amp;&amp; and=
 return std::fiber. The fiber instance returned by fn() is, in turn, used a=
s the return value for the suspended function: resume() or resume_with().<b=
r></blockquote><br>That paragraph needs to be changed too. I&#39;d say it s=
hould look like the following:<br><br><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;"><i>An injected function fn() must accept std::fiber&am=
p;&amp; and return std::fiber. The fiber instance returned by fn() is, in t=
urn, used as the return value for the previously executed suspended functio=
n in the fiber: resume() or resume_with(). If there was no previously execu=
ted suspend function, then the return value will be passed as the parameter=
 of the entry-function.</i><br></blockquote></div><br></div>

<p></p>

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

------=_Part_11794_1453448440.1520785253586--

------=_Part_11793_339716816.1520785253586--

.

------=_Part_14302_1258692078.1520846488613
Content-Type: multipart/alternative;
 boundary="----=_Part_14303_324804423.1520846488613"

------=_Part_14303_324804423.1520846488613
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sunday, March 11, 2018 at 5:41:09 PM UTC+3, Oliver Kowalke wrote:
>
> Oh, and one other thing. The proposal says this:
>
>>
>> When calling `resume()`, it is conventional to replace the=20
>>> newly-invalidated instance =E2=80=93 the instance on which `resume()` w=
as called =E2=80=93=20
>>> with the new instance returned by that `resume()` call. This helps to a=
void=20
>>> inadvertent calls to `resume()` on the old, invalidated instance.
>>>
>>
>> That sounds like a good convention. So maybe there should be a couple of=
=20
>> global helper functions to help people adhere to it:
>>
>> void resume(std::fiber &&f) {f =3D std::move(f).resume();}
>>
>> template<typename Fn>
>> void resume_with(std::fiber &&f, Fn &&fn) {f =3D std::move(f).resume_wit=
h(
>> std::forward<Fn>(fn));}
>>
>> These could be member functions (with the names `resume_inplace` and=20
>> `resume_with_inplace`) instead of free functions.
>>
>
> yes, sounds reasonable
>

Why && ? Shouldn't it be old good lvalue reference in this case?

void resume(std::fiber &f) {f =3D std::move(f).resume();}

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/af419e1f-3c34-4adb-97fa-cdb48f6442a8%40isocpp.or=
g.

------=_Part_14303_324804423.1520846488613
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, March 11, 2018 at 5:41:09 PM UTC+3, Oli=
ver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Oh, and one other thing. The proposal says this:<br><div><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">When calling `resume()`, it i=
s conventional to replace the newly-invalidated instance =E2=80=93 the inst=
ance on which `resume()` was called =E2=80=93 with the new instance returne=
d by that `resume()` call. This helps to avoid inadvertent calls to `resume=
()` on the old, invalidated instance.<br></blockquote><br>That sounds like =
a good convention. So maybe there should be a couple of global helper funct=
ions to help people adhere to it:<br><br><div style=3D"background-color:rgb=
(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width=
:1px"><code><div><span style=3D"color:#008">void</span><span style=3D"color=
:#000"> resume</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:=
#000">fiber </span><span style=3D"color:#660">&amp;&amp;</span><span style=
=3D"color:#000">f</span><span style=3D"color:#660">)</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:=
#000">f </span><span style=3D"color:#660">=3D</span><span style=3D"color:#0=
00"> std</span><span style=3D"color:#660">::</span><span style=3D"color:#00=
0">move</span><span style=3D"color:#660">(</span><span style=3D"color:#000"=
>f</span><span style=3D"color:#660">).</span><span style=3D"color:#000">res=
ume</span><span style=3D"color:#660">();}</span><span style=3D"color:#000">=
<br><br></span><span style=3D"color:#008">template</span><span style=3D"col=
or:#660">&lt;</span><span style=3D"color:#008">typename</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Fn</span><span style=3D"=
color:#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D=
"color:#008">void</span><span style=3D"color:#000"> resume_with</span><span=
 style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span st=
yle=3D"color:#660">::</span><span style=3D"color:#000">fiber </span><span s=
tyle=3D"color:#660">&amp;&amp;</span><span style=3D"color:#000">f</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#606">Fn</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">&amp;&amp;</span><span style=3D"color:#000">fn</span><span =
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000">f </span><span style=3D"=
color:#660">=3D</span><span style=3D"color:#000"> std</span><span style=3D"=
color:#660">::</span><span style=3D"color:#000">move</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#000">f</span><span style=3D"color:=
#660">).</span><span style=3D"color:#000">resume_with</span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">std</span><span style=3D"col=
or:#660">::</span><span style=3D"color:#000"><wbr>forward</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#606">Fn</span><span style=
=3D"color:#660">&gt;(</span><span style=3D"color:#000">fn</span><span style=
=3D"color:#660">));}</span></div></code></div><br>These could be member fun=
ctions (with the names `resume_inplace` and `resume_with_inplace`) instead =
of free functions.<br></div></div></blockquote></div><br></div><div>yes, so=
unds reasonable<br></div></div></blockquote><div><br>Why &amp;&amp; ? Shoul=
dn&#39;t it be old good lvalue reference in this case?<br><br><code><span s=
tyle=3D"color:#008">void</span><span style=3D"color:#000"> resume</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span =
style=3D"color:#660">::</span><span style=3D"color:#000">fiber </span><span=
 style=3D"color:#660">&amp;</span><span style=3D"color:#000">f</span><span =
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000">f </span><span style=3D"=
color:#660">=3D</span><span style=3D"color:#000"> std</span><span style=3D"=
color:#660">::</span><span style=3D"color:#000">move</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#000">f</span><span style=3D"color:=
#660">).</span><span style=3D"color:#000">resume</span><span style=3D"color=
:#660">();}<br><br></span></code></div></div>

<p></p>

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

------=_Part_14303_324804423.1520846488613--

------=_Part_14302_1258692078.1520846488613--

.

--94eb2c1bca9436b8b7056733e623
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2018-03-12 10:21 GMT+01:00 Victor Dyachenko <victor.dyachenko@gmail.com>:

>
>
> On Sunday, March 11, 2018 at 5:41:09 PM UTC+3, Oliver Kowalke wrote:
>>
>> Oh, and one other thing. The proposal says this:
>>
>>>
>>> When calling `resume()`, it is conventional to replace the
>>>> newly-invalidated instance =E2=80=93 the instance on which `resume()` =
was called =E2=80=93
>>>> with the new instance returned by that `resume()` call. This helps to =
avoid
>>>> inadvertent calls to `resume()` on the old, invalidated instance.
>>>>
>>>
>>> That sounds like a good convention. So maybe there should be a couple o=
f
>>> global helper functions to help people adhere to it:
>>>
>>> void resume(std::fiber &&f) {f =3D std::move(f).resume();}
>>>
>>> template<typename Fn>
>>> void resume_with(std::fiber &&f, Fn &&fn) {f =3D std::move(f).resume_wi=
th(
>>> std::forward<Fn>(fn));}
>>>
>>> These could be member functions (with the names `resume_inplace` and
>>> `resume_with_inplace`) instead of free functions.
>>>
>>
>> yes, sounds reasonable
>>
>
> Why && ? Shouldn't it be old good lvalue reference in this case?
>
> void resume(std::fiber &f) {f =3D std::move(f).resume();}
>
>
resume() invalidates the instance of f ... resume() with the signature
`fiber resume() &&` (=3D=3D can only be invoked at rvalue references) -> se=
e
P0876

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CA%2Bwfc1-oAV8McW5oDbyiYiRY2HzyW0-anvoEXcMe_Ze2s=
9%3D_SQ%40mail.gmail.com.

--94eb2c1bca9436b8b7056733e623
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2018-03-12 10:21 GMT+01:00 Victor Dyachenko <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blank">victor.dyachenko=
@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><span class=3D""><br><br>On Sunday, March 11, 2018 at 5:41:09 PM UTC+3, =
Oliver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">Oh, and one other thing. The proposal says this:<br><div><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">When calling `resume()`, it is =
conventional to replace the newly-invalidated instance =E2=80=93 the instan=
ce on which `resume()` was called =E2=80=93 with the new instance returned =
by that `resume()` call. This helps to avoid inadvertent calls to `resume()=
` on the old, invalidated instance.<br></blockquote><br>That sounds like a =
good convention. So maybe there should be a couple of global helper functio=
ns to help people adhere to it:<br><br><div style=3D"background-color:rgb(2=
50,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1=
px"><code><div><span style=3D"color:#008">void</span><span style=3D"color:#=
000"> resume</span><span style=3D"color:#660">(</span><span style=3D"color:=
#000">std</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">fiber </span><span style=3D"color:#660">&amp;&amp;</span><span style=3D=
"color:#000">f</span><span style=3D"color:#660">)</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#00=
0">f </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"=
> std</span><span style=3D"color:#660">::</span><span style=3D"color:#000">=
move</span><span style=3D"color:#660">(</span><span style=3D"color:#000">f<=
/span><span style=3D"color:#660">).</span><span style=3D"color:#000">resume=
</span><span style=3D"color:#660">();}</span><span style=3D"color:#000"><br=
><br></span><span style=3D"color:#008">template</span><span style=3D"color:=
#660">&lt;</span><span style=3D"color:#008">typename</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#606">Fn</span><span style=3D"color=
:#660">&gt;</span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#008">void</span><span style=3D"color:#000"> resume_with</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">fiber </span><span styl=
e=3D"color:#660">&amp;&amp;</span><span style=3D"color:#000">f</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Fn</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">&amp;&amp;</span><span style=3D"color:#000">fn</span><span styl=
e=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000">f </span><span style=3D"colo=
r:#660">=3D</span><span style=3D"color:#000"> std</span><span style=3D"colo=
r:#660">::</span><span style=3D"color:#000">move</span><span style=3D"color=
:#660">(</span><span style=3D"color:#000">f</span><span style=3D"color:#660=
">).</span><span style=3D"color:#000">resume_with</span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#000">std</span><span style=3D"color:#=
660">::</span><span style=3D"color:#000"><wbr>forward</span><span style=3D"=
color:#660">&lt;</span><span style=3D"color:#606">Fn</span><span style=3D"c=
olor:#660">&gt;(</span><span style=3D"color:#000">fn</span><span style=3D"c=
olor:#660">));}</span></div></code></div><br>These could be member function=
s (with the names `resume_inplace` and `resume_with_inplace`) instead of fr=
ee functions.<br></div></div></blockquote></div><br></div><div>yes, sounds =
reasonable<br></div></div></blockquote></span><div><br>Why &amp;&amp; ? Sho=
uldn&#39;t it be old good lvalue reference in this case?<br><br><code><span=
 style=3D"color:#008">void</span><span style=3D"color:#000"> resume</span><=
span style=3D"color:#660">(</span><span style=3D"color:#000">std</span><spa=
n style=3D"color:#660">::</span><span style=3D"color:#000">fiber </span><sp=
an style=3D"color:#660">&amp;</span><span style=3D"color:#000">f</span><spa=
n style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#660">{</span><span style=3D"color:#000">f </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">move</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">f</span><span style=3D"c=
olor:#660">).</span><span style=3D"color:#000">resume</span><span style=3D"=
color:#660">();}<br><br></span></code></div></div></blockquote><div><br></d=
iv><div>resume() invalidates the instance of f ... resume() with the signat=
ure `fiber resume() &amp;&amp;` (=3D=3D can only be invoked at rvalue refer=
ences) -&gt; see P0876<br></div></div><br></div></div>

<p></p>

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

--94eb2c1bca9436b8b7056733e623--

.

------=_Part_14262_1845074208.1520847614397
Content-Type: multipart/alternative;
 boundary="----=_Part_14263_1235348657.1520847614398"

------=_Part_14263_1235348657.1520847614398
Content-Type: text/plain; charset="UTF-8"

But this function doesn't invalidate f! It is an input/output param here

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8217f43c-eb85-410b-ab82-b476e5096f7a%40isocpp.org.

------=_Part_14263_1235348657.1520847614398
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">But this function doesn&#39;t invalidate f! It is an input=
/output param here<br><br></div>

<p></p>

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

------=_Part_14263_1235348657.1520847614398--

------=_Part_14262_1845074208.1520847614397--

.

--000000000000fe23ae056733f708
Content-Type: text/plain; charset="UTF-8"

2018-03-12 10:40 GMT+01:00 Victor Dyachenko <victor.dyachenko@gmail.com>:

> But this function doesn't invalidate f! It is an input/output param here
>

resume() invalidates instance `f`, restricting to rvalue reference makes
this more explicit to the user

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-BPbGyTpfnY4KW9qC1wnWOVRhXiBfYk%3Dt95F56eqotxQ%40mail.gmail.com.

--000000000000fe23ae056733f708
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2018-03-12 10:40 GMT+01:00 Victor Dyachenko <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:victor.dyachenko@gmail.com" target=3D"_blank">victor.dyachenko=
@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">But this function doesn&#39;t invalidate f! It is an input/output param =
here<br></div></blockquote></div><br></div><div class=3D"gmail_extra">resum=
e() invalidates instance `f`, restricting to rvalue reference makes this mo=
re explicit to the user<br></div></div>

<p></p>

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

--000000000000fe23ae056733f708--

.

------=_Part_15069_1696696307.1520868337552
Content-Type: multipart/alternative;
 boundary="----=_Part_15070_705273613.1520868337552"

------=_Part_15070_705273613.1520868337552
Content-Type: text/plain; charset="UTF-8"

On Monday, March 12, 2018 at 5:43:07 AM UTC-4, Oliver Kowalke wrote:
>
> 2018-03-12 10:40 GMT+01:00 Victor Dyachenko <victor.d...@gmail.com
> <javascript:>>:
>
>> But this function doesn't invalidate f! It is an input/output param here
>>
>
> resume() invalidates instance `f`, restricting to rvalue reference makes
> this more explicit to the user
>

On the one hand, I understand what you're getting at. But on the other
hand, the function also assigns to `f`, which means that `f` will likely
remain valid after the call.

Normally, if you do `some_function(std::move(val))`, you expect that `val`
is no longer valid. We're taught as C++ programmers to assume this when
reading that code and to either not use `val` anymore or to reinitialize
`val` before using it again.

`resume(std::move(f))` will leave `f` in a meaningful state. Even if `f` is
not in a valid state, the fact that it's not valid is *meaningful* to the
user. It means something that the resumed fiber didn't return a valid fiber
to suspend to. The fiber likely terminated successfully or something.

`std::move(val)` is supposed to be read as "I'm done with this now". But in
this case, you're *not* done with `f` now. So if the intent of the
interface is to assign to the given reference, such that it retains meaning
relative to the operation, then the interface should not require
`std::move`.

Also, using a `&&` parameter means that you can do this:

resume(std::fiber(...));

Which is probably not what you wanted. That code will have the same effect
as

std::fiber(...).resume();

But that's precisely why the first code *shouldn't* compile. The non-member
function is for doing an in-place operation. And if you're doing an
in-place operation, you really want it to work on lvalues only, since the
point of the in-place operation is to resume a *variable* and assign back
to it.

As such, it should take an lvalue reference.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d1923101-b20b-4ae9-ab9f-319c12d32c93%40isocpp.org.

------=_Part_15070_705273613.1520868337552
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 12, 2018 at 5:43:07 AM UTC-4, Oliver Kowa=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">2018-03-12 10:40 GMT+01:00 Victor Dyachenko <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"zlCOc4vHAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">victor.d...@gmail.com</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">But this function doesn&#39;t invalidate f! =
It is an input/output param here<br></div></blockquote></div><br></div><div=
>resume() invalidates instance `f`, restricting to rvalue reference makes t=
his more explicit to the user<br></div></div></blockquote><div><br>On the o=
ne hand, I understand what you&#39;re getting at. But on the other hand, th=
e function also assigns to `f`, which means that `f` will likely remain val=
id after the call.<br><br>Normally, if you do `some_function(std::move(val)=
)`, you expect that `val` is no longer valid. We&#39;re taught as C++ progr=
ammers to assume this when reading that code and to either not use `val` an=
ymore or to reinitialize `val` before using it again.<br><br>`resume(std::m=
ove(f))` will leave `f` in a meaningful state. Even if `f` is not in a vali=
d state, the fact that it&#39;s not valid is <i>meaningful</i> to the user.=
 It means something that the resumed fiber didn&#39;t return a valid fiber =
to suspend to. The fiber likely terminated successfully or something.<br><b=
r>`std::move(val)` is supposed to be read as &quot;I&#39;m done with this n=
ow&quot;. But in this case, you&#39;re <i>not</i> done with `f` now. So if =
the intent of the interface is to assign to the given reference, such that =
it retains meaning relative to the operation, then the interface should not=
 require `std::move`.<br><br>Also, using a `&amp;&amp;` parameter means tha=
t you can do this:<br><br><div style=3D"background-color: rgb(250, 250, 250=
); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px=
; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">resume</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">fiber</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(...));</span><=
/div></code></div><br>Which is probably not what you wanted. That code will=
 have the same effect as<br><br><div style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">fiber</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(...).</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
resume</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
</div></code></div><br>But that&#39;s precisely why the first code <i>shoul=
dn&#39;t</i> compile. The non-member function is for doing an in-place oper=
ation. And if you&#39;re doing an in-place operation, you really want it to=
 work on lvalues only, since the point of the in-place operation is to resu=
me a <i>variable</i> and assign back to it.<br><br>As such, it should take =
an lvalue reference.<br></div></div>

<p></p>

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

------=_Part_15070_705273613.1520868337552--

------=_Part_15069_1696696307.1520868337552--

.

------=_Part_19258_257883323.1520963848874
Content-Type: multipart/alternative;
 boundary="----=_Part_19259_632655720.1520963848874"

------=_Part_19259_632655720.1520963848874
Content-Type: text/plain; charset="UTF-8"

On Monday, March 12, 2018 at 11:25:37 AM UTC-4, Nicol Bolas wrote:
>
> On Monday, March 12, 2018 at 5:43:07 AM UTC-4, Oliver Kowalke wrote:
>>
>> 2018-03-12 10:40 GMT+01:00 Victor Dyachenko <victor.d...@gmail.com>:
>>
>>> But this function doesn't invalidate f! It is an input/output param here
>>>
>>
>> resume() invalidates instance `f`, restricting to rvalue reference makes
>> this more explicit to the user
>>
>
> On the one hand, I understand what you're getting at. But on the other
> hand, the function also assigns to `f`, which means that `f` will likely
> remain valid after the call.
>
> Normally, if you do `some_function(std::move(val))`, you expect that `val`
> is no longer valid. We're taught as C++ programmers to assume this when
> reading that code and to either not use `val` anymore or to reinitialize
> `val` before using it again.
>
> `resume(std::move(f))` will leave `f` in a meaningful state. Even if `f`
> is not in a valid state, the fact that it's not valid is *meaningful* to
> the user. It means something that the resumed fiber didn't return a valid
> fiber to suspend to. The fiber likely terminated successfully or something.
>
> `std::move(val)` is supposed to be read as "I'm done with this now". But
> in this case, you're *not* done with `f` now. So if the intent of the
> interface is to assign to the given reference, such that it retains meaning
> relative to the operation, then the interface should not require
> `std::move`.
>
> Also, using a `&&` parameter means that you can do this:
>
> resume(std::fiber(...));
>
> Which is probably not what you wanted. That code will have the same effect
> as
>
> std::fiber(...).resume();
>
> But that's precisely why the first code *shouldn't* compile. The
> non-member function is for doing an in-place operation. And if you're doing
> an in-place operation, you really want it to work on lvalues only, since
> the point of the in-place operation is to resume a *variable* and assign
> back to it.
>
> As such, it should take an lvalue reference.
>

Ah, in addition to this, I would suggest that the members `resume` and
`resume_with` are prime candidates for the [[nodiscard]] attribute.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/165e9050-9dc4-4923-a592-6cf57920bcee%40isocpp.org.

------=_Part_19259_632655720.1520963848874
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 12, 2018 at 11:25:37 AM UTC-4, Nicol Bola=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Mo=
nday, March 12, 2018 at 5:43:07 AM 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"><div dir=3D"ltr"><div><div class=3D"gmail_quote=
">2018-03-12 10:40 GMT+01:00 Victor Dyachenko <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">victor.d...@gmail.com</a>&gt;</span>:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">But this function doesn&#39;t invalidate f! It =
is an input/output param here<br></div></blockquote></div><br></div><div>re=
sume() invalidates instance `f`, restricting to rvalue reference makes this=
 more explicit to the user<br></div></div></blockquote><div><br>On the one =
hand, I understand what you&#39;re getting at. But on the other hand, the f=
unction also assigns to `f`, which means that `f` will likely remain valid =
after the call.<br><br>Normally, if you do `some_function(std::move(val))<w=
br>`, you expect that `val` is no longer valid. We&#39;re taught as C++ pro=
grammers to assume this when reading that code and to either not use `val` =
anymore or to reinitialize `val` before using it again.<br><br>`resume(std:=
:move(f))` will leave `f` in a meaningful state. Even if `f` is not in a va=
lid state, the fact that it&#39;s not valid is <i>meaningful</i> to the use=
r. It means something that the resumed fiber didn&#39;t return a valid fibe=
r to suspend to. The fiber likely terminated successfully or something.<br>=
<br>`std::move(val)` is supposed to be read as &quot;I&#39;m done with this=
 now&quot;. But in this case, you&#39;re <i>not</i> done with `f` now. So i=
f the intent of the interface is to assign to the given reference, such tha=
t it retains meaning relative to the operation, then the interface should n=
ot require `std::move`.<br><br>Also, using a `&amp;&amp;` parameter means t=
hat you can do this:<br><br><div style=3D"background-color:rgb(250,250,250)=
;border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><=
div><span style=3D"color:#000">resume</span><span style=3D"color:#660">(</s=
pan><span style=3D"color:#000">std</span><span style=3D"color:#660">::</spa=
n><span style=3D"color:#000">fiber</span><span style=3D"color:#660">(...));=
</span></div></code></div><br>Which is probably not what you wanted. That c=
ode will have the same effect as<br><br><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px"><code><div><span style=3D"color:#000">std</span><span style=3D"color:#=
660">::</span><span style=3D"color:#000">fiber</span><span style=3D"color:#=
660">(...).</span><span style=3D"color:#000">resume</span><span style=3D"co=
lor:#660">();</span><span style=3D"color:#000"><br></span></div></code></di=
v><br>But that&#39;s precisely why the first code <i>shouldn&#39;t</i> comp=
ile. The non-member function is for doing an in-place operation. And if you=
&#39;re doing an in-place operation, you really want it to work on lvalues =
only, since the point of the in-place operation is to resume a <i>variable<=
/i> and assign back to it.<br><br>As such, it should take an lvalue referen=
ce.<br></div></div></blockquote><div><br>Ah, in addition to this, I would s=
uggest that the members `resume` and `resume_with` are prime candidates for=
 the [[nodiscard]] attribute.<br></div></div>

<p></p>

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

------=_Part_19259_632655720.1520963848874--

------=_Part_19258_257883323.1520963848874--

.

------=_Part_20008_1130915443.1521648076506
Content-Type: multipart/alternative;
 boundary="----=_Part_20009_519759698.1521648076506"

------=_Part_20009_519759698.1521648076506
Content-Type: text/plain; charset="UTF-8"



> * Fibers are bound to the thread that initially created them; they cannot
> be resumed in any other thread. Is this restriction necessary?
>

TLS limitation is due to how TLS codegen is done on RISC CPUs today:

https://godbolt.org/g/ZyrTTc

TLS access is expensive, registers are cheap, so, on the first TLS access,
compiler caches the address of the TLS page in some callee saved register
used throughout the function.
Compiler has no idea that a call to a different function might switch
stacks / TLS underneath.
If a fiber is suspended and resumed on a different thread, register used as
the beginning of the TLS page may be pointing at the  memory that is gone
or have been reused for something else.

Note that it is not the user written code. It is how compiler makes TLS
access efficient within a function. Allowing fiber resumption on different
thread, would require pessimizing TLS access for every function by
reloading TLS after every function call.

If we cannot safely access TLS, it means that it is likely that:
* magic statics do not work
* error_code category does not work
* tc_malloc (thread caching allocator) does not work
* networking TS / asio does not work (it uses a thread caching recycling
allocator by default)
* more stuff is broken

Stackless coroutines do not have this problem, since the points where
suspension and resumption can happen are marked explicitly and compiler
does not caches TLS across suspend points.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1265f8b5-e9f9-4b08-881f-51b49ed67357%40isocpp.org.

------=_Part_20009_519759698.1521648076506
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><br style=3D"background-attachment: scroll; backgroun=
d-clip: border-box; background-color: transparent; background-image: none; =
background-origin: padding-box; background-position-x: 0%; background-posit=
ion-y: 0%; background-repeat: repeat; background-size: auto; border-bottom-=
color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px=
; border-image-outset: 0; border-image-repeat: stretch; border-image-slice:=
 100%; border-image-source: none; border-image-width: 1; border-left-color:=
 rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border-r=
ight-color: rgb(34, 34, 34); border-right-style: none; border-right-width: =
0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-=
width: 0px; color: rgb(34, 34, 34); font-family: &amp;quot;Arial&amp;quot;,=
&amp;quot;Helvetica&amp;quot;,sans-serif; font-size: 13px; font-style: norm=
al; font-variant: normal; font-weight: 400; height: auto; letter-spacing: n=
ormal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top:=
 0px; min-width: 0px; orphans: 2; overflow: visible; overflow-x: visible; o=
verflow-y: visible; padding-bottom: 0px; padding-left: 0px; padding-right: =
0px; padding-top: 0px; text-align: left; text-decoration: none; text-indent=
: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: n=
ormal; word-spacing: 0px;"><blockquote class=3D"gmail_quote" style=3D"backg=
round-color: transparent; border-left-color: rgb(204, 204, 204); border-lef=
t-style: solid; border-left-width: 1px; color: rgb(34, 34, 34); font-family=
: &amp;quot;Arial&amp;quot;,&amp;quot;Helvetica&amp;quot;,sans-serif; font-=
size: 13px; font-style: normal; font-variant: normal; font-weight: 400; let=
ter-spacing: normal; margin-bottom: 0px; margin-left: 5.38px; margin-right:=
 0px; margin-top: 0px; orphans: 2; padding-left: 6.73px; text-align: left; =
text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text=
-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><div style=3D"=
border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bot=
tom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; borde=
r-image-slice: 100%; border-image-source: none; border-image-width: 1; bord=
er-left-color: rgb(34, 34, 34); border-left-style: none; border-left-width:=
 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; border=
-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: non=
e; border-top-width: 0px; margin-bottom: 0px; margin-left: 0px; margin-righ=
t: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-ri=
ght: 0px; padding-top: 0px;" dir=3D"ltr">* Fibers are bound to the thread t=
hat initially created them; they cannot be resumed in any other thread. Is =
this restriction necessary? </div></blockquote><b></b><i></i><u></u><sub></=
sub><sup></sup><strike></strike><br></div><div>TLS limitation is due to how=
 TLS codegen is done on RISC CPUs today:</div><div><br></div><div>https://g=
odbolt.org/g/ZyrTTc</div><div><br></div><div>TLS access is expensive, regis=
ters are cheap, so, on the first TLS access, compiler caches the address of=
 the TLS page in some callee saved register used throughout the function.=
=C2=A0</div><div>Compiler has no idea that a call to a different function m=
ight switch stacks / TLS underneath.</div><div>If a fiber is suspended and =
resumed on a different thread, register used as the beginning of the TLS pa=
ge may be pointing at the=C2=A0 memory that is gone or have been reused for=
 something else.</div><div><br></div><div>Note that it is not the user writ=
ten code. It is how compiler makes TLS access efficient within a function. =
Allowing fiber resumption on different thread, would require pessimizing TL=
S access for every function by reloading TLS after every function call.</di=
v><div><br></div><div>If we cannot safely access TLS, it means that it is l=
ikely that:</div><div>* magic statics do not work</div><div>* error_code ca=
tegory does not work</div><div>* tc_malloc (thread caching allocator) does =
not work</div><div>* networking TS / asio does not work (it uses a thread c=
aching recycling allocator by default)</div><div>* more stuff is broken</di=
v><div><br></div><div>Stackless coroutines do not have this problem, since =
the points where suspension and resumption can happen are marked explicitly=
 and compiler does not caches TLS across suspend points.</div><div><br></di=
v><div><br></div></div>

<p></p>

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

------=_Part_20009_519759698.1521648076506--

------=_Part_20008_1130915443.1521648076506--

.

--0000000000004437190567ef49b3
Content-Type: text/plain; charset="UTF-8"

2018-03-21 17:01 GMT+01:00 Gor Nishanov <gornishanov@gmail.com>:

<snip>


> Stackless coroutines do not have this problem, since the points where
> suspension and resumption can happen are marked explicitly and compiler
> does not caches TLS across suspend points.
>

the TLS problem is not P0876 specific ... it applies to any C++ code that
uses TLS (thread_local vars) and moves functors between threads
migrating fibers between threads is possible if not TLS is used

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-fy7XxQXLQ%2BLpBhwpX%2B%2BhV7b%3DMpLTDNzEuiv2o51M4mQ%40mail.gmail.com.

--0000000000004437190567ef49b3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2018-03-21 17:01 GMT+01:00 Gor Nishanov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:gornishanov@gmail.com" target=3D"_blank">gornishanov@gmail.com</=
a>&gt;</span>:<br><div><br></div><div>&lt;snip&gt;<br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Stackless=
 coroutines do not have this problem, since the points where suspension and=
 resumption can happen are marked explicitly and compiler does not caches T=
LS across suspend points.</div></div></blockquote><div><br></div><div>the T=
LS problem is not P0876 specific ... it applies to any C++ code that uses T=
LS (thread_local vars) and moves functors between threads<br></div><div>mig=
rating fibers between threads is possible if not TLS is used<br></div></div=
></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-fy7XxQXLQ%2BLpBhwpX%2B%2BhV=
7b%3DMpLTDNzEuiv2o51M4mQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwf=
c1-fy7XxQXLQ%2BLpBhwpX%2B%2BhV7b%3DMpLTDNzEuiv2o51M4mQ%40mail.gmail.com</a>=
..<br />

--0000000000004437190567ef49b3--

.

------=_Part_15812_997940482.1521655809554
Content-Type: multipart/alternative;
 boundary="----=_Part_15813_1267378618.1521655809555"

------=_Part_15813_1267378618.1521655809555
Content-Type: text/plain; charset="UTF-8"

Hmm... My reply got deleted. Let me repost it again:

<snip>

On Wednesday, March 21, 2018 at 10:11:50 AM UTC-7, Oliver Kowalke wrote:

the TLS problem is not P0876 specific ... it applies to any C++ code that
> uses TLS (thread_local vars) and moves functors between threads
> migrating fibers between threads is possible if not TLS is used
>

Functor running in different threads is perfectly legal and does not
produce hidden undefined behavior.
You can use all of the language, all of the libraries, you will always
correctly get the TLS of the thread which is executing the code.
There is no UB. Since the operator() of the function object always
completely executes in a thread and you will always get a TLS of a thread
which is executing

Of course, a user can write a UB, by say, taking an address of a thread
local variable and stashing it somewhere and then referencing it later. I
am not talking about user writing a buggy code,
I am talking about the instructions that compiler generates for TLS access.
Compilers assume that entire function executes completely in one thread,
therefore they are free to cache TLS page load in non-scratch registers.
std::fiber breaks that, since now, in a function that looks normal to the
compiler, at any function call there could be a fiber switch and subsequent
TLS access in that function will become UB.

This is important point, I'll stay engaged in this thread until this is
resolved. You being a primary author on fibers paper should understand that
SG1 did not demand changes because of their ignorance. To my knowledge,
nobody knows at the moment how to make fibers work across threads without
introducing TLS related UB.

Note that some standard library and language features under the covers use
TLS. Even if you do not use TLS in your code and none of the 3rd party
libraries use TLS, you would still have TLS access from the facilities I
mentioned in my earlier post.

Cheers,
Gor


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1b2edffd-fd23-4af3-a618-478dadc9250a%40isocpp.org.

------=_Part_15813_1267378618.1521655809555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hmm... My reply got deleted. Let me repost it again:<=
/div><div><br></div><div>&lt;snip&gt;</div><br><div>On Wednesday, March 21,=
 2018 at 10:11:50 AM UTC-7, Oliver Kowalke wrote:</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div>the TLS problem is not P0876 specific ... it applies to =
any C++ code that uses TLS (thread_local vars) and moves functors between t=
hreads<br></div><div>migrating fibers between threads is possible if not TL=
S is used<br></div></div></div></div></blockquote><div><br></div><div><div =
style=3D"background-color: transparent; color: rgb(34, 34, 34); direction: =
ltr; font-family: arial,sans-serif; font-size: 12.8px; font-style: normal; =
font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bott=
om: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; =
padding-bottom: 0px; position: static; text-align: left; text-decoration: n=
one; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px=
; white-space: normal; word-spacing: 0px;">Functor running in different thr=
eads is perfectly legal and does not produce hidden undefined behavior.</di=
v><div style=3D"background-color: transparent; color: rgb(34, 34, 34); dire=
ction: ltr; font-family: arial,sans-serif; font-size: 12.8px; font-style: n=
ormal; font-variant: normal; font-weight: 400; letter-spacing: normal; marg=
in-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orpha=
ns: 2; padding-bottom: 0px; position: static; text-align: left; text-decora=
tion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-wid=
th: 0px; white-space: normal; word-spacing: 0px;">You can use all of the la=
nguage, all of the libraries, you will always correctly get the TLS of the =
thread which is executing the code.</div><div style=3D"background-color: tr=
ansparent; color: rgb(34, 34, 34); direction: ltr; font-family: arial,sans-=
serif; font-size: 12.8px; font-style: normal; font-variant: normal; font-we=
ight: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; ma=
rgin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; position=
: static; text-align: left; text-decoration: none; text-indent: 0px; text-t=
ransform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-s=
pacing: 0px;">There is no UB. Since the operator() of the function object a=
lways completely executes in a thread and you will always get a TLS of a th=
read which is executing=C2=A0</div><div style=3D"background-color: transpar=
ent; color: rgb(34, 34, 34); direction: ltr; font-family: arial,sans-serif;=
 font-size: 12.8px; font-style: normal; font-variant: normal; font-weight: =
400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-r=
ight: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; position: stat=
ic; text-align: left; text-decoration: none; text-indent: 0px; text-transfo=
rm: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing=
: 0px;"><br style=3D"direction: ltr; font-size: 12.8px; margin-bottom: 0px;=
 margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px;=
 position: static;"></div><div style=3D"background-color: transparent; colo=
r: rgb(34, 34, 34); direction: ltr; font-family: arial,sans-serif; font-siz=
e: 12.8px; font-style: normal; font-variant: normal; font-weight: 400; lett=
er-spacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px=
; margin-top: 0px; orphans: 2; padding-bottom: 0px; position: static; text-=
align: left; text-decoration: none; text-indent: 0px; text-transform: none;=
 -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;">O=
f course, a user can write a UB, by say, taking an address of a thread loca=
l variable and stashing it somewhere and then referencing it later. I am no=
t talking about user writing a buggy code,=C2=A0<br style=3D"direction: ltr=
; font-size: 12.8px; margin-bottom: 0px; margin-left: 0px; margin-right: 0p=
x; margin-top: 0px; padding-bottom: 0px; position: static;"></div><div styl=
e=3D"background-color: transparent; color: rgb(34, 34, 34); direction: ltr;=
 font-family: arial,sans-serif; font-size: 12.8px; font-style: normal; font=
-variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: =
0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padd=
ing-bottom: 0px; position: static; text-align: left; text-decoration: none;=
 text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; wh=
ite-space: normal; word-spacing: 0px;">I am talking about the instructions =
that compiler generates for TLS access. Compilers assume that entire functi=
on executes completely in one thread, therefore they are free to cache TLS =
page load in non-scratch registers. std::fiber breaks that, since now, in a=
 function that looks normal to the compiler, at any function call there cou=
ld be a fiber switch and subsequent TLS access in that function will become=
 UB.</div><div style=3D"background-color: transparent; color: rgb(34, 34, 3=
4); direction: ltr; font-family: arial,sans-serif; font-size: 12.8px; font-=
style: normal; font-variant: normal; font-weight: 400; letter-spacing: norm=
al; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0p=
x; orphans: 2; padding-bottom: 0px; position: static; text-align: left; tex=
t-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-st=
roke-width: 0px; white-space: normal; word-spacing: 0px;"><br style=3D"dire=
ction: ltr; font-size: 12.8px; margin-bottom: 0px; margin-left: 0px; margin=
-right: 0px; margin-top: 0px; padding-bottom: 0px; position: static;"></div=
><div style=3D"background-color: transparent; color: rgb(34, 34, 34); direc=
tion: ltr; font-family: arial,sans-serif; font-size: 12.8px; font-style: no=
rmal; font-variant: normal; font-weight: 400; letter-spacing: normal; margi=
n-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphan=
s: 2; padding-bottom: 0px; position: static; text-align: left; text-decorat=
ion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-widt=
h: 0px; white-space: normal; word-spacing: 0px;">This is important point, I=
&#39;ll stay engaged in this thread until this is resolved. You being a pri=
mary author on fibers paper should understand that SG1 did not demand chang=
es because of their ignorance. To my knowledge, nobody knows at the moment =
how to make fibers work across threads without introducing TLS related UB.<=
/div><div style=3D"background-color: transparent; color: rgb(34, 34, 34); d=
irection: ltr; font-family: arial,sans-serif; font-size: 12.8px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; m=
argin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; or=
phans: 2; padding-bottom: 0px; position: static; text-align: left; text-dec=
oration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-=
width: 0px; white-space: normal; word-spacing: 0px;"><br style=3D"direction=
: ltr; font-size: 12.8px; margin-bottom: 0px; margin-left: 0px; margin-righ=
t: 0px; margin-top: 0px; padding-bottom: 0px; position: static;"></div><div=
 style=3D"background-color: transparent; color: rgb(34, 34, 34); direction:=
 ltr; font-family: arial,sans-serif; font-size: 12.8px; font-style: normal;=
 font-variant: normal; font-weight: 400; letter-spacing: normal; margin-bot=
tom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2;=
 padding-bottom: 0px; position: static; text-align: left; text-decoration: =
none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0p=
x; white-space: normal; word-spacing: 0px;">Note that some standard library=
 and language features under the covers use TLS. Even if you do not use TLS=
 in your code and none of the 3rd party libraries use TLS, you would still =
have TLS access from the facilities I mentioned in my earlier post.</div><d=
iv style=3D"background-color: transparent; color: rgb(34, 34, 34); directio=
n: ltr; font-family: arial,sans-serif; font-size: 12.8px; font-style: norma=
l; font-variant: normal; font-weight: 400; letter-spacing: normal; margin-b=
ottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: =
2; padding-bottom: 0px; position: static; text-align: left; text-decoration=
: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: =
0px; white-space: normal; word-spacing: 0px;"><br style=3D"direction: ltr; =
font-size: 12.8px; margin-bottom: 0px; margin-left: 0px; margin-right: 0px;=
 margin-top: 0px; padding-bottom: 0px; position: static;"></div><div style=
=3D"background-color: transparent; color: rgb(34, 34, 34); direction: ltr; =
font-family: arial,sans-serif; font-size: 12.8px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; position: static; text-align: left; text-decoration: none; =
text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; whi=
te-space: normal; word-spacing: 0px;">Cheers,</div><div style=3D"background=
-color: transparent; color: rgb(34, 34, 34); direction: ltr; font-family: a=
rial,sans-serif; font-size: 12.8px; font-style: normal; font-variant: norma=
l; font-weight: 400; letter-spacing: normal; margin-bottom: 0px; margin-lef=
t: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px=
; position: static; text-align: left; text-decoration: none; text-indent: 0=
px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norm=
al; word-spacing: 0px;">Gor</div>=C2=A0</div></div>

<p></p>

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

------=_Part_15813_1267378618.1521655809555--

------=_Part_15812_997940482.1521655809554--

.

------=_Part_15511_3524938.1521655913328
Content-Type: multipart/alternative;
 boundary="----=_Part_15512_86099209.1521655913329"

------=_Part_15512_86099209.1521655913329
Content-Type: text/plain; charset="UTF-8"



On Wednesday, March 21, 2018 at 1:11:50 PM UTC-4, Oliver Kowalke wrote:
>
>
>
> 2018-03-21 17:01 GMT+01:00 Gor Nishanov <gorni...@gmail.com <javascript:>>
> :
>
> <snip>
>
>
>> Stackless coroutines do not have this problem, since the points where
>> suspension and resumption can happen are marked explicitly and compiler
>> does not caches TLS across suspend points.
>>
>
> the TLS problem is not P0876 specific ... it applies to any C++ code that
> uses TLS (thread_local vars) and moves functors between threads
>

Gor doesn't seem to be talking about general logic issues behind TLS. He's
talking about a specific implementation of TLS that conflicts with
arbitrary suspend/resume of unprepared functions.

In the case Gor's talking about, there is an actual register/stack value
that functions use to access TLS values. So a fiber suspend/resume will
preserve the TLS values. Which means if you resume it on another thread, it
will be using the values from the *previous* thread. But this will only be
the case for such implementations.

Simply passing a functor to a different thread won't cause that problem. It
only happens if you start the function on one thread and complete it on
another.

"Stackless coroutines" don't have that problem because the compiler knows
that this *specific* function can be suspended/resumed on different
threads, and at those points it can take steps to adjust the appropriate
registers/stack values as needed.

And as Gor points out, there's a lot of hidden code out there that
implicitly uses TLS. So simply saying "fibers can be transferred as long as
you don't use TLS" doesn't really solve the problem.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8094c5a1-6e49-495f-9bb0-80887aa711ea%40isocpp.org.

------=_Part_15512_86099209.1521655913329
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 21, 2018 at 1:11:50 PM UTC-4, =
Oliver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div><br><div class=3D"gmail_quote">2018-03-21 17:01 GMT+01:00=
 Gor Nishanov <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"nz_XVz1zAQAJ" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;=
javascript:&#39;;return true;">gorni...@gmail.com</a>&gt;</span>:<br><div><=
br></div><div>&lt;snip&gt;<br></div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div></div><div>Stackless coroutines do not have =
this problem, since the points where suspension and resumption can happen a=
re marked explicitly and compiler does not caches TLS across suspend points=
..</div></div></blockquote><div><br></div><div>the TLS problem is not P0876 =
specific ... it applies to any C++ code that uses TLS (thread_local vars) a=
nd moves functors between threads<br></div></div></div></div></blockquote><=
div><br>Gor doesn&#39;t seem to be talking about general logic issues behin=
d TLS. He&#39;s talking about a specific implementation of TLS that conflic=
ts with arbitrary suspend/resume of unprepared functions.<br><br>In the cas=
e Gor&#39;s talking about, there is an actual register/stack value that fun=
ctions use to access TLS values. So a fiber suspend/resume will preserve th=
e TLS values. Which means if you resume it on another thread, it will be us=
ing the values from the <i>previous</i> thread. But this will only be the c=
ase for such implementations.<br><br>Simply passing a functor to a differen=
t thread won&#39;t cause that problem. It only happens if you start the fun=
ction on one thread and complete it on another.<br><br>&quot;Stackless coro=
utines&quot; don&#39;t have that problem because the compiler knows that th=
is <i>specific</i> function can be suspended/resumed on different threads, =
and at those points it can take steps to adjust the appropriate registers/s=
tack values as needed.<br><br>And as Gor points out, there&#39;s a lot of h=
idden code out there that implicitly uses TLS. So simply saying &quot;fiber=
s can be transferred as long as you don&#39;t use TLS&quot; doesn&#39;t rea=
lly solve the problem.<br></div></div>

<p></p>

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

------=_Part_15512_86099209.1521655913329--

------=_Part_15511_3524938.1521655913328--

.

--000000000000a23f1a0567f02f33
Content-Type: text/plain; charset="UTF-8"

the point is: don't use TLS if you want to migrate fibers to other threads

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19TxLFJjcZt-O7yj46u0Jp40VxkBwePM9wxW%3DcJ7CV43w%40mail.gmail.com.

--000000000000a23f1a0567f02f33
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">the point is: don&#39;t use TLS if you want to migrate fib=
ers to other threads<br></div>

<p></p>

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

--000000000000a23f1a0567f02f33--

.

------=_Part_16129_1763333988.1521656499471
Content-Type: multipart/alternative;
 boundary="----=_Part_16130_662706775.1521656499471"

------=_Part_16130_662706775.1521656499471
Content-Type: text/plain; charset="UTF-8"

On Wednesday, March 21, 2018 at 2:16:15 PM UTC-4, Oliver Kowalke wrote:
>
> the point is: don't use TLS if you want to migrate fibers to other threads
>

How do you define "use TLS"? As pointed out, a lot of things "use TLS".
Some implementations may use TLS for something that other implementations
do not.

The standard cannot define that some things don't "use TLS". So how will
you know what you can and cannot do with transferable fibers?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2eecbc50-7337-4e40-bbf5-6536d14ef8b9%40isocpp.org.

------=_Part_16130_662706775.1521656499471
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 21, 2018 at 2:16:15 PM UTC-4, Oliver K=
owalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
the point is: don&#39;t use TLS if you want to migrate fibers to other thre=
ads<br></div></blockquote><div><br>How do you define &quot;use TLS&quot;? A=
s pointed out, a lot of things &quot;use TLS&quot;. Some implementations ma=
y use TLS for something that other implementations do not.<br><br>The stand=
ard cannot define that some things don&#39;t &quot;use TLS&quot;. So how wi=
ll you know what you can and cannot do with transferable fibers? <br></div>=
</div>

<p></p>

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

------=_Part_16130_662706775.1521656499471--

------=_Part_16129_1763333988.1521656499471--

.

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

> the point is: don't use TLS if you want to migrate fibers to other threads

Which means, do not use <filesystem>, do not define static locals within a
function, do not use <system_error>, do not use errno, do not use
init_once, do not use networking TS, do not use boost::asio and these are
just the ones on top of my head of the things which are popular and using
thread_local in their implementation.

It is difficult to provide an exhaustive list of all facilities that you
should not use if you want to migrate fibers to other threads.

Though, as you probably saw, there is a provision of adding special "expert
only" members to std::fiber API that can resume the fiber in a different
thread. The burden is of course, is those who use those would have to have
super detail code reviews that nothing in what they use can ever touch TLS
today or when maintaining this code and upgrading to later revisions of
libraries or compiler features.


On Wed, Mar 21, 2018 at 11:15 AM, Oliver Kowalke <oliver.kowalke@gmail.com>
wrote:

> the point is: don't use TLS if you want to migrate fibers to other threads
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJ4Vuxva850GEp6n6xVPHbNU77Hj-niCB-W%3D-pGTeELOV6%3DmOQ%40mail.gmail.com.

--001a113f3174eb72c70567f04bf8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt;=C2=A0<span style=3D"text-align:left;color:rgb(34=
,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-fami=
ly:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant:normal;=
font-weight:400;text-decoration:none;word-spacing:0px;display:inline;white-=
space:normal;direction:ltr;float:none;background-color:transparent">the poi=
nt is: don&#39;t use TLS if you want to migrate fibers to other threads</sp=
an></div><div><br></div><div>Which means, do not use &lt;filesystem&gt;, do=
 not define static locals within a function, do not use &lt;system_error&gt=
;, do not use errno, do not use init_once, do not use networking TS, do not=
 use boost::asio and these are just the ones on top of my head of the thing=
s which are popular and using thread_local in their implementation.</div><d=
iv><br></div><div>It is difficult to provide an exhaustive list of all faci=
lities that you should not use if you want to migrate fibers to other threa=
ds.</div><div><br></div><div>Though, as you probably saw, there is a provis=
ion of adding special &quot;expert only&quot; members to std::fiber API tha=
t can resume the fiber in a different thread. The burden is of course, is t=
hose who use those would have to have super detail code reviews that nothin=
g in what they use can ever touch TLS today or when maintaining this code a=
nd upgrading to later revisions of libraries or compiler features.</div><di=
v><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On We=
d, Mar 21, 2018 at 11:15 AM, 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"ma=
rgin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);=
border-left-width:1px;border-left-style:solid"><div dir=3D"ltr">the point i=
s: don&#39;t use TLS if you want to migrate fibers to other threads<br></di=
v>
</blockquote></div><br></div></div>

<p></p>

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

--001a113f3174eb72c70567f04bf8--

.

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

On Wed, Mar 21, 2018 at 12:01 PM, Gor Nishanov <gornishanov@gmail.com>
wrote:

>
> * Fibers are bound to the thread that initially created them; they cannot
>> be resumed in any other thread. Is this restriction necessary?
>>
>
> TLS limitation is due to how TLS codegen is done on RISC CPUs today:
>
> https://godbolt.org/g/ZyrTTc
>

I am just an interested observer trying to understand this thread (sic).
May I
ask what the fiber suspension/resumption activity has to do with TLS? I am
struggling to make this connection. Are we saying that code that uses TLS
and ends up being executed by a Fiber cannot possibly work correctly if it
resumes in another thread?

Raymond Chen over here[1] seems to imply that Fibers can quite happily get
themselves suspended by the thread that created them and simply resume on
another thread.

[1] https://blogs.msdn.microsoft.com/oldnewthing/20100225-00/?p=14813/

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALEPxfuaiWumSDCHd-OQznUM%3D%3DA3M3SWUS83O0uZa1TyXJByfw%40mail.gmail.com.

--001a114131fef034000567f08d71
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Mar 21, 2018 at 12:01 PM, Gor Nishanov <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:gornishanov@gmail.com" target=3D"_blank">gornishanov@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr"><div><br><blockquote class=3D"gmail_quote"><div style=3D"b=
order-color:rgb(34,34,34);border-style:none;border-width:0px;margin:0px;pad=
ding:0px" dir=3D"ltr">* Fibers are bound to the thread that initially creat=
ed them; they cannot be resumed in any other thread. Is this restriction ne=
cessary? </div></blockquote><b></b><i></i><u></u><sub></sub><sup></sup><str=
ike></strike><br></div><div>TLS limitation is due to how TLS codegen is don=
e on RISC CPUs today:</div><div><br></div><div><a href=3D"https://godbolt.o=
rg/g/ZyrTTc" target=3D"_blank">https://godbolt.org/g/ZyrTTc</a></div></div>=
</blockquote><div><br></div><div>I am just an interested observer trying to=
 understand this thread (sic). May I=C2=A0</div><div>ask what the fiber sus=
pension/resumption activity has to do with TLS? I am=C2=A0</div><div>strugg=
ling to make this connection. Are we saying that code that uses TLS=C2=A0</=
div><div>and ends up being executed by a Fiber cannot possibly work correct=
ly if it=C2=A0</div><div>resumes in another thread?</div><div><br></div><di=
v>Raymond Chen over here[1] seems to imply that Fibers can quite happily ge=
t=C2=A0</div><div>themselves suspended by the thread that created them and =
simply resume on=C2=A0</div><div>another thread.</div><div><br></div><div>[=
1]=C2=A0<a href=3D"https://blogs.msdn.microsoft.com/oldnewthing/20100225-00=
/?p=3D14813/">https://blogs.msdn.microsoft.com/oldnewthing/20100225-00/?p=
=3D14813/</a></div></div></div></div>

<p></p>

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

--001a114131fef034000567f08d71--

.

------=_Part_11251_661286993.1521660454902
Content-Type: multipart/alternative;
 boundary="----=_Part_11252_2012507534.1521660454902"

------=_Part_11252_2012507534.1521660454902
Content-Type: text/plain; charset="UTF-8"

On Wednesday, March 21, 2018 at 2:42:37 PM UTC-4, Dilip R wrote:
>
> On Wed, Mar 21, 2018 at 12:01 PM, Gor Nishanov <gorni...@gmail.com
> <javascript:>> wrote:
>
>>
>> * Fibers are bound to the thread that initially created them; they cannot
>>> be resumed in any other thread. Is this restriction necessary?
>>>
>>
>> TLS limitation is due to how TLS codegen is done on RISC CPUs today:
>>
>> https://godbolt.org/g/ZyrTTc
>>
>
> I am just an interested observer trying to understand this thread (sic).
> May I
> ask what the fiber suspension/resumption activity has to do with TLS? I am
> struggling to make this connection. Are we saying that code that uses TLS
> and ends up being executed by a Fiber cannot possibly work correctly if it
> resumes in another thread?
>

Yes, that's what he's saying. In the implementation he's referring to,
getting TLS data requires going though a pointer in a register or stack
value. As such, those registers/stack will be preserved across threads. So
TLS access will access the wrong thread's local storage.


> Raymond Chen over here[1] seems to imply that Fibers can quite happily get
> themselves suspended by the thread that created them and simply resume on
> another thread.
>
> [1] https://blogs.msdn.microsoft.com/oldnewthing/20100225-00/?p=14813/
>

He's talking about a very specific implementation of fibers on a very
specific CPU and compiler setup with a very specific way of handling TLS.
Gor is talking about different implementations of TLS which are
incompatible with fibers being executed on different threads.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4a494986-8ae8-4568-b535-76bd1934b2ba%40isocpp.org.

------=_Part_11252_2012507534.1521660454902
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 21, 2018 at 2:42:37 PM UTC-4, Dilip R =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote">On Wed, Mar 21, 2018 at 12:01 PM, Gor Nishanov <sp=
an dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"eOvfrjF4AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">gorni...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br><blockquote clas=
s=3D"gmail_quote"><div style=3D"border-color:rgb(34,34,34);border-style:non=
e;border-width:0px;margin:0px;padding:0px" dir=3D"ltr">* Fibers are bound t=
o the thread that initially created them; they cannot be resumed in any oth=
er thread. Is this restriction necessary? </div></blockquote><b></b><i></i>=
<u></u><sub></sub><sup></sup><strike></strike><br></div><div>TLS limitation=
 is due to how TLS codegen is done on RISC CPUs today:</div><div><br></div>=
<div><a href=3D"https://godbolt.org/g/ZyrTTc" target=3D"_blank" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps=
%3A%2F%2Fgodbolt.org%2Fg%2FZyrTTc\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG=
at-b4AkH_NH8SwHx3bP_BmaQPzQ&#39;;return true;" onclick=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FZyrTTc\x26s=
a\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGat-b4AkH_NH8SwHx3bP_BmaQPzQ&#39;;retur=
n true;">https://godbolt.org/g/ZyrTTc</a></div></div></blockquote><div><br>=
</div><div>I am just an interested observer trying to understand this threa=
d (sic). May I=C2=A0</div><div>ask what the fiber suspension/resumption act=
ivity has to do with TLS? I am=C2=A0</div><div>struggling to make this conn=
ection. Are we saying that code that uses TLS=C2=A0</div><div>and ends up b=
eing executed by a Fiber cannot possibly work correctly if it=C2=A0</div><d=
iv>resumes in another thread?</div></div></div></div></blockquote><div><br>=
Yes, that&#39;s what he&#39;s saying. In the implementation he&#39;s referr=
ing to, getting TLS data requires going though a pointer in a register or s=
tack value. As such, those registers/stack will be preserved across threads=
.. So TLS access will access the wrong thread&#39;s local storage.<br>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><d=
iv class=3D"gmail_quote"><div>Raymond Chen over here[1] seems to imply that=
 Fibers can quite happily get=C2=A0</div><div>themselves suspended by the t=
hread that created them and simply resume on=C2=A0</div><div>another thread=
..</div><div><br></div><div>[1]=C2=A0<a href=3D"https://blogs.msdn.microsoft=
..com/oldnewthing/20100225-00/?p=3D14813/" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%=
2F%2Fblogs.msdn.microsoft.com%2Foldnewthing%2F20100225-00%2F%3Fp%3D14813%2F=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFHsNcprnLcM8WEP9mrxnC8BS3jng&#39;;=
return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dh=
ttps%3A%2F%2Fblogs.msdn.microsoft.com%2Foldnewthing%2F20100225-00%2F%3Fp%3D=
14813%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFHsNcprnLcM8WEP9mrxnC8BS3j=
ng&#39;;return true;">https://blogs.msdn.<wbr>microsoft.com/oldnewthing/<wb=
r>20100225-00/?p=3D14813/</a></div></div></div></div></blockquote><div><br>=
He&#39;s talking about a very specific implementation of fibers on a very s=
pecific CPU and compiler setup with a very specific way of handling TLS. Go=
r is talking about different implementations of TLS which are incompatible =
with fibers being executed on different threads.<br></div></div>

<p></p>

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

------=_Part_11252_2012507534.1521660454902--

------=_Part_11251_661286993.1521660454902--

.

------=_Part_21039_1119880736.1521672069269
Content-Type: multipart/alternative;
 boundary="----=_Part_21040_1479820770.1521672069269"

------=_Part_21040_1479820770.1521672069269
Content-Type: text/plain; charset="UTF-8"



Den onsdag 21 mars 2018 kl. 19:24:09 UTC+1 skrev Gor Nishanov:
>
> > the point is: don't use TLS if you want to migrate fibers to other
> threads
>
> Which means, do not use <filesystem>, do not define static locals within a
> function, do not use <system_error>, do not use errno, do not use
> init_once, do not use networking TS, do not use boost::asio and these are
> just the ones on top of my head of the things which are popular and using
> thread_local in their implementation.
>

I don't think it is this bad: As long as a function inside for instance
std::filesystem does not yield it should be ok to call it from a fiber even
if said fiber jumps between threads. If on the other hand you have a
callback from a function using thread_local and that function yields you
are in trouble, if I understand the register usage correctly.

With both thread_local and fiber being part of the language that the
compiler vendor is to implement there should be possibilities to improve
the situation further. For instance, if a *specific *register could be
reserved for the TLS page pointer use then the only thing needed would be
for the fiber switch function to *not* preserve this register. Thus the TLS
page pointer would always be consistent with the running thread.

It is still unclear to me if there is just one TLS "page" per thread or if
each of the thread_local variables have their own "page" which may require
reserving multiple registers. Maybe you can explain this system in more
detail?

In some cases this would not solve the thread jumping of fibers anyway, for
instance in the case of errno: Some asynchronous IO function may set errno
then call the user provided callback which supposedly checks for errors
using errno. But if this callback yields before checking errno and is
subsequently resumed in another thread the errno will be wrong. (I'm not at
all advocating for this errno usage, its just an example). Even without
multithreading I see the potential error source with errno and similar as
fibers are typically used for asynchronous IO making it very easy to make
mistakes so that multiple fibers can execute code setting errno overwriting
each other's values... Do we need fiber_local storage?

Bengt


>
> It is difficult to provide an exhaustive list of all facilities that you
> should not use if you want to migrate fibers to other threads.
>
> Though, as you probably saw, there is a provision of adding special
> "expert only" members to std::fiber API that can resume the fiber in a
> different thread. The burden is of course, is those who use those would
> have to have super detail code reviews that nothing in what they use can
> ever touch TLS today or when maintaining this code and upgrading to later
> revisions of libraries or compiler features.
>
>
> On Wed, Mar 21, 2018 at 11:15 AM, Oliver Kowalke <oliver....@gmail.com
> <javascript:>> wrote:
>
>> the point is: don't use TLS if you want to migrate fibers to other threads
>>
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/27e1722a-161c-499a-8f0d-fb6b321512e9%40isocpp.org.

------=_Part_21040_1479820770.1521672069269
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Den onsdag 21 mars 2018 kl. 19:24:09 UTC+1 skrev G=
or Nishanov:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>&gt;=C2=A0<span style=3D"text-align:left;color:rgb(34,34,34);text-trans=
form:none;text-indent:0px;letter-spacing:normal;font-family:arial,sans-seri=
f;font-size:12.8px;font-style:normal;font-variant:normal;font-weight:400;te=
xt-decoration:none;word-spacing:0px;display:inline;white-space:normal;direc=
tion:ltr;float:none;background-color:transparent">the point is: don&#39;t u=
se TLS if you want to migrate fibers to other threads</span></div><div><br>=
</div><div>Which means, do not use &lt;filesystem&gt;, do not define static=
 locals within a function, do not use &lt;system_error&gt;, do not use errn=
o, do not use init_once, do not use networking TS, do not use boost::asio a=
nd these are just the ones on top of my head of the things which are popula=
r and using thread_local in their implementation.</div></div></blockquote><=
div><br></div><div>I don&#39;t think it is this bad: As long as a function =
inside for instance std::filesystem does not yield it should be ok to call =
it from a fiber even if said fiber jumps between threads. If on the other h=
and you have a callback from a function using thread_local and that functio=
n yields you are in trouble, if I understand the register usage correctly.<=
/div><div><br></div><div>With both thread_local and fiber being part of the=
 language that the compiler vendor is to implement there should be possibil=
ities to improve the situation further. For instance, if a <i>specific </i>=
register could be reserved for the TLS page pointer use then the only thing=
 needed would be for the fiber switch function to <i>not</i> preserve this =
register. Thus the TLS page pointer would always be consistent with the run=
ning thread.</div><div><br></div><div>It is still unclear to me if there is=
 just one TLS &quot;page&quot; per thread or if each of the thread_local va=
riables have their own &quot;page&quot; which may require reserving multipl=
e registers. Maybe you can explain this system in more detail?</div><div><b=
r></div><div>In some cases this would not solve the thread jumping of fiber=
s anyway, for instance in the case of errno: Some asynchronous IO function =
may set errno then call the user provided callback which supposedly checks =
for errors using errno. But if this callback yields before checking errno a=
nd is subsequently resumed in another thread the errno will be wrong. (I&#3=
9;m not at all advocating for this errno usage, its just an example). Even =
without multithreading I see the potential error source with errno and simi=
lar as fibers are typically used for asynchronous IO making it very easy to=
 make mistakes so that multiple fibers can execute code setting errno overw=
riting each other&#39;s values... Do we need fiber_local storage?=C2=A0=C2=
=A0</div><div><br></div><div>Bengt</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div>It is diff=
icult to provide an exhaustive list of all facilities that you should not u=
se if you want to migrate fibers to other threads.</div><div><br></div><div=
>Though, as you probably saw, there is a provision of adding special &quot;=
expert only&quot; members to std::fiber API that can resume the fiber in a =
different thread. The burden is of course, is those who use those would hav=
e to have super detail code reviews that nothing in what they use can ever =
touch TLS today or when maintaining this code and upgrading to later revisi=
ons of libraries or compiler features.</div><div><br></div><div><br><div cl=
ass=3D"gmail_quote">On Wed, Mar 21, 2018 at 11:15 AM, Oliver Kowalke <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"aSFSmC93AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">oliver....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-=
left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">=
<div dir=3D"ltr">the point is: don&#39;t use TLS if you want to migrate fib=
ers to other threads<br></div>
</blockquote></div><br></div></div>
</blockquote></div>

<p></p>

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

------=_Part_21040_1479820770.1521672069269--

------=_Part_21039_1119880736.1521672069269--

.

------=_Part_8241_902941504.1522051751028
Content-Type: multipart/alternative;
 boundary="----=_Part_8242_864773081.1522051751028"

------=_Part_8242_864773081.1522051751028
Content-Type: text/plain; charset="UTF-8"


On Wednesday, March 21, 2018 at 10:41:09 PM UTC, Bengt Gustafsson wrote:
>
>
> Den onsdag 21 mars 2018 kl. 19:24:09 UTC+1 skrev Gor Nishanov:
>>
>> > the point is: don't use TLS if you want to migrate fibers to other
>> threads
>>
>> Which means, do not use <filesystem>, do not define static locals within
>> a function, do not use <system_error>, do not use errno, do not use
>> init_once, do not use networking TS, do not use boost::asio and these are
>> just the ones on top of my head of the things which are popular and using
>> thread_local in their implementation.
>>
>
> I don't think it is this bad: As long as a function inside for instance
> std::filesystem does not yield it should be ok to call it from a fiber even
> if said fiber jumps between threads.
>

That's not the case unfortunately. Because of inlining and interprocedural
optimizations. If you call the same function (or two functions that access
the same TLS entry) before and after a yield point, the compiler might
still unsafely optimize the TLS access.

-- gpd

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/438fb818-da1f-4f18-8acd-131c9372baec%40isocpp.org.

------=_Part_8242_864773081.1522051751028
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, March 21, 2018 at 10:41:09 PM UTC, Bengt=
 Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br>Den onsdag 21 mars 2018 kl. 19:24:09 UTC+1 skrev Gor Nishanov:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>&gt;=C2=A0<span s=
tyle=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent=
:0px;letter-spacing:normal;font-family:arial,sans-serif;font-size:12.8px;fo=
nt-style:normal;font-variant:normal;font-weight:400;text-decoration:none;wo=
rd-spacing:0px;display:inline;white-space:normal;direction:ltr;float:none;b=
ackground-color:transparent">the point is: don&#39;t use TLS if you want to=
 migrate fibers to other threads</span></div><div><br></div><div>Which mean=
s, do not use &lt;filesystem&gt;, do not define static locals within a func=
tion, do not use &lt;system_error&gt;, do not use errno, do not use init_on=
ce, do not use networking TS, do not use boost::asio and these are just the=
 ones on top of my head of the things which are popular and using thread_lo=
cal in their implementation.</div></div></blockquote><div><br></div><div>I =
don&#39;t think it is this bad: As long as a function inside for instance s=
td::filesystem does not yield it should be ok to call it from a fiber even =
if said fiber jumps between threads.</div></div></blockquote><div><br>That&=
#39;s not the case unfortunately. Because of inlining and interprocedural o=
ptimizations. If you call the same function (or two functions that access t=
he same TLS entry) before and after a yield point, the compiler might still=
 unsafely optimize the TLS access. <br><br>-- gpd<br></div></div>

<p></p>

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

------=_Part_8242_864773081.1522051751028--

------=_Part_8241_902941504.1522051751028--

.

------=_Part_15614_2042153938.1522103526675
Content-Type: multipart/alternative;
 boundary="----=_Part_15615_1587476732.1522103526675"

------=_Part_15615_1587476732.1522103526675
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On the other hand we are talking about a new language feature here. Even if=
=20
a fiber is disguised as a class there has to be some codegen magic to make=
=20
yielding happen. Yes, boost manages to do it with some assembly function=20
but I assume a language feature would be handled by the compiler in such a=
=20
way that it can detect a yield point and abstain from caching a TLS entry=
=20
pointer in a register over it.

If the language feature is specified in this way it will gain an edge over=
=20
boost's library only version that may increase the motivation to actually=
=20
standardize it. This said it is not obvious that current uses of TLS will=
=20
continue to work if you slap yield points into the code at random but it=20
should at least be possible to ensure that the TLS entry corresponds to the=
=20
current thread at all times.

I could be wrong but I think that there are interesting use cases for=20
fibers that can be served by a thread pool. As it may be impossible to know=
=20
if a library uses TLS it seems scary to not allow the limited usage I=20
proposed (i.e. still no yielding in callbacks).


Den m=C3=A5ndag 26 mars 2018 kl. 10:09:11 UTC+2 skrev Giovanni Piero Derett=
a:
>
>
> On Wednesday, March 21, 2018 at 10:41:09 PM UTC, Bengt Gustafsson wrote:
>>
>>
>> Den onsdag 21 mars 2018 kl. 19:24:09 UTC+1 skrev Gor Nishanov:
>>>
>>> > the point is: don't use TLS if you want to migrate fibers to other=20
>>> threads
>>>
>>> Which means, do not use <filesystem>, do not define static locals withi=
n=20
>>> a function, do not use <system_error>, do not use errno, do not use=20
>>> init_once, do not use networking TS, do not use boost::asio and these a=
re=20
>>> just the ones on top of my head of the things which are popular and usi=
ng=20
>>> thread_local in their implementation.
>>>
>>
>> I don't think it is this bad: As long as a function inside for instance=
=20
>> std::filesystem does not yield it should be ok to call it from a fiber e=
ven=20
>> if said fiber jumps between threads.
>>
>
> That's not the case unfortunately. Because of inlining and interprocedura=
l=20
> optimizations. If you call the same function (or two functions that acces=
s=20
> the same TLS entry) before and after a yield point, the compiler might=20
> still unsafely optimize the TLS access.=20
>
> -- gpd
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/6702c66a-59a5-40ae-aba7-763b581331ef%40isocpp.or=
g.

------=_Part_15615_1587476732.1522103526675
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On the other hand we are talking about a new language feat=
ure here. Even if a fiber is disguised as a class there has to be some code=
gen magic to make yielding happen. Yes, boost manages to do it with some as=
sembly function but I assume a language feature would be handled by the com=
piler in such a way that it can detect a yield point and abstain from cachi=
ng a TLS entry pointer in a register over it.<div><br></div><div>If the lan=
guage feature is specified in this way it will gain an edge over boost&#39;=
s library only version that may increase the motivation to actually standar=
dize it. This said it is not obvious that current uses of TLS will continue=
 to work if you slap yield points into the code at random but it should at =
least be possible to ensure that the TLS entry corresponds to the current t=
hread at all times.</div><div><br></div><div>I could be wrong but I think t=
hat there are interesting use cases for fibers that can be served by a thre=
ad pool. As it may be impossible to know if a library uses TLS it seems sca=
ry to not allow the limited usage I proposed (i.e. still no yielding in cal=
lbacks).</div><div><br><br>Den m=C3=A5ndag 26 mars 2018 kl. 10:09:11 UTC+2 =
skrev Giovanni Piero Deretta:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><br>On Wednesday, March 21, 2018 at 10:41:09 PM UTC, Bengt =
Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
br>Den onsdag 21 mars 2018 kl. 19:24:09 UTC+1 skrev Gor Nishanov:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>&gt;=C2=A0<span style=
=3D"text-align:left;color:rgb(34,34,34);text-transform:none;text-indent:0px=
;letter-spacing:normal;font-family:arial,sans-serif;font-size:12.8px;font-s=
tyle:normal;font-variant:normal;font-weight:400;text-decoration:none;word-s=
pacing:0px;display:inline;white-space:normal;direction:ltr;float:none;backg=
round-color:transparent">the point is: don&#39;t use TLS if you want to mig=
rate fibers to other threads</span></div><div><br></div><div>Which means, d=
o not use &lt;filesystem&gt;, do not define static locals within a function=
, do not use &lt;system_error&gt;, do not use errno, do not use init_once, =
do not use networking TS, do not use boost::asio and these are just the one=
s on top of my head of the things which are popular and using thread_local =
in their implementation.</div></div></blockquote><div><br></div><div>I don&=
#39;t think it is this bad: As long as a function inside for instance std::=
filesystem does not yield it should be ok to call it from a fiber even if s=
aid fiber jumps between threads.</div></div></blockquote><div><br>That&#39;=
s not the case unfortunately. Because of inlining and interprocedural optim=
izations. If you call the same function (or two functions that access the s=
ame TLS entry) before and after a yield point, the compiler might still uns=
afely optimize the TLS access. <br><br>-- gpd<br></div></div></blockquote><=
/div></div>

<p></p>

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

------=_Part_15615_1587476732.1522103526675--

------=_Part_15614_2042153938.1522103526675--

.

------=_Part_14470_385519281.1522104361961
Content-Type: multipart/alternative;
 boundary="----=_Part_14471_1132942724.1522104361962"

------=_Part_14471_1132942724.1522104361962
Content-Type: text/plain; charset="UTF-8"

On Monday, March 26, 2018 at 6:32:06 PM UTC-4, Bengt Gustafsson wrote:
>
> On the other hand we are talking about a new language feature here. Even
> if a fiber is disguised as a class there has to be some codegen magic to
> make yielding happen.
>

Just because there's "codegen magic" doesn't make it a "language feature".
This is a pure library extension; any changes to the language parts of the
standard would only be to clarify the behavior of fibers with respect to
mutexes, data races, and other async coding.


> Yes, boost manages to do it with some assembly function but I assume a
> language feature would be handled by the compiler in such a way that it can
> detect a yield point and abstain from caching a TLS entry pointer in a
> register over it.
>

I don't know all of the details of these sorts of implementations, so I may
be off-base here. But the way I see it, that could only work if the
compiler can see all of the code between the function that is initially
called in the fiber and every fiber suspension point. That is, if
everything is inline (ala the resumable functions proposal).

Because otherwise, the compiler cannot know that a particular function call
will eventually invoke a yield operation. And without that knowledge, it
won't know that it should not cache the TLS pointer or to refresh that
cache at some later date. And if it gets cached, that could be cached on
the stack somewhere, where it can become incorrect relative to resumption
on a different thread.

This is why the coroutines TS doesn't have this problem; within each
coroutine, every possible suspend point is explicitly spelled out in the
text of that function.

If the language feature is specified in this way it will gain an edge over
> boost's library only version that may increase the motivation to actually
> standardize it. This said it is not obvious that current uses of TLS will
> continue to work if you slap yield points into the code at random but it
> should at least be possible to ensure that the TLS entry corresponds to the
> current thread at all times.
>
> I could be wrong but I think that there are interesting use cases for
> fibers that can be served by a thread pool. As it may be impossible to know
> if a library uses TLS it seems scary to not allow the limited usage I
> proposed (i.e. still no yielding in callbacks).
>

I think what would be good is if there is an implementation-defined query
that you can set up telling you whether it's OK to share fibers between
threads. If we accept that some implementations just can't allow that, it
would be nice to at least be able to write code for those that do allow it,
with a `static_assert` preventing it from working on other implementations.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fdbbbec4-c4f2-457c-8423-7d1c2252e3da%40isocpp.org.

------=_Part_14471_1132942724.1522104361962
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, March 26, 2018 at 6:32:06 PM UTC-4, Bengt Gusta=
fsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n the other hand we are talking about a new language feature here. Even if =
a fiber is disguised as a class there has to be some codegen magic to make =
yielding happen.</div></blockquote><div><br>Just because there&#39;s &quot;=
codegen magic&quot; doesn&#39;t make it a &quot;language feature&quot;. Thi=
s is a pure library extension; any changes to the language parts of the sta=
ndard would only be to clarify the behavior of fibers with respect to mutex=
es, data races, and other async coding.<br>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr">Yes, boost manages to do it with =
some assembly function but I assume a language feature would be handled by =
the compiler in such a way that it can detect a yield point and abstain fro=
m caching a TLS entry pointer in a register over it.</div></blockquote><div=
><br>I don&#39;t know all of the details of these sorts of implementations,=
 so I may be off-base here. But the way I see it, that could only work if t=
he compiler can see all of the code between the function that is initially =
called in the fiber and every fiber suspension point. That is, if everythin=
g is inline (ala the resumable functions proposal).<br><br>Because otherwis=
e, the compiler cannot know that a particular function call will eventually=
 invoke a yield operation. And without that knowledge, it won&#39;t know th=
at it should not cache the TLS pointer or to refresh that cache at some lat=
er date. And if it gets cached, that could be cached on the stack somewhere=
, where it can become incorrect relative to resumption on a different threa=
d.<br><br>This is why the coroutines TS doesn&#39;t have this problem; with=
in each coroutine, every possible suspend point is explicitly spelled out i=
n the text of that function.<br><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div></div><div>If the language feature is spe=
cified in this way it will gain an edge over boost&#39;s library only versi=
on that may increase the motivation to actually standardize it. This said i=
t is not obvious that current uses of TLS will continue to work if you slap=
 yield points into the code at random but it should at least be possible to=
 ensure that the TLS entry corresponds to the current thread at all times.<=
/div><div><br></div><div>I could be wrong but I think that there are intere=
sting use cases for fibers that can be served by a thread pool. As it may b=
e impossible to know if a library uses TLS it seems scary to not allow the =
limited usage I proposed (i.e. still no yielding in callbacks).</div></div>=
</blockquote><div><br>I think what would be good is if there is an implemen=
tation-defined query that you can set up telling you whether it&#39;s OK to=
 share fibers between threads. If we accept that some implementations just =
can&#39;t allow that, it would be nice to at least be able to write code fo=
r those that do allow it, with a `static_assert` preventing it from working=
 on other implementations. <br></div></div>

<p></p>

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

------=_Part_14471_1132942724.1522104361962--

------=_Part_14470_385519281.1522104361961--

.