------=_Part_44366_504920400.1530047995863
Content-Type: multipart/alternative;
 boundary="----=_Part_44367_1406294960.1530047995863"

------=_Part_44367_1406294960.1530047995863
Content-Type: text/plain; charset="UTF-8"

Reading over both the Unified Executors Proposal
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0443r5.html) and
the Unified Futures Proposal
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1054r0.html), as
well as some earlier papers discussing the topic
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0008r0.pdf), it
seems one of the unresolved areas for further consideration is how, or to
what extent, thread pool execution context behavior after shutdown should
be standardized, particularly with regard to outstanding
futures/continuations associated with a thread pool executor.

While this is a broad topic, I've been thinking particularly about what
really should happen when say, you have a Future with N attached
continuations, and the associated thread pool execution context stops.
Many questions come to mind, such as: Does execution stop after executing
the current continuation?  Does it stop after executing *all *attached
continuations?  Does it stop after executing the current continuation but
then set a broken_promise exception?  If so, how can it even execute an
attached exception handler for the broken promise exception when the
execution context shouldn't be accepting further work?  What if *a second* thread
pool has a chained future that is waiting for the readiness of a future
that is associated with the shutting down thread pool?  Should the shutting
down executor set a broken promise exception so that the second executor
can continue (and not just wait forever?)  Should this happen right after
the call to thread_pool.stop(), or should it happen when the first thread
pool object's destructor is invoked?  Perhaps none of these questions can
be answered until a more comprehensive discussion about Future cancellation
is explored.

I can't find any published papers that really try to comprehensively
explore these questions.  The closest I found was
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0008r0.pdf, which
discusses various options for thread pool shutdown, but discusses it only
with "one-way" tasks in mind, not "two-way channel" tasks.

Are there are papers or discussion threads out there that explore this in
depth, with the latest Unified Executor/Unified Futures proposal in mind?

--
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/9eb859b1-7a6b-47d1-b455-7e02d6740225%40isocpp.org.

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

<div dir=3D"ltr">Reading over both the Unified Executors Proposal (http://w=
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0443r5.html) and the Unifi=
ed Futures Proposal (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
8/p1054r0.html), as well as some earlier papers discussing the topic (http:=
//www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0008r0.pdf), it seems o=
ne of the unresolved areas for further consideration is how, or to what ext=
ent, thread pool execution context behavior after shutdown should be standa=
rdized, particularly with regard to outstanding futures/continuations assoc=
iated with a thread pool executor.<div><br></div><div>While this is a broad=
 topic, I&#39;ve been thinking particularly about what really should happen=
 when say, you have a Future with N attached continuations, and the associa=
ted thread pool execution context stops.=C2=A0 Many questions come to mind,=
 such as: Does execution stop after executing the current continuation?=C2=
=A0 Does it stop after executing <i>all </i>attached continuations?=C2=A0 D=
oes it stop after executing the current continuation but then set a broken_=
promise exception?=C2=A0 If so, how can it even execute an attached excepti=
on handler for the broken promise exception when the execution context shou=
ldn&#39;t be accepting further work?=C2=A0 What if <i>a second</i>=C2=A0thr=
ead pool has a chained future that is waiting for the readiness of a future=
 that is associated with the shutting down thread pool?=C2=A0 Should the sh=
utting down executor set a broken promise exception so that the second exec=
utor can continue (and not just wait forever?)=C2=A0 Should this happen rig=
ht after the call to thread_pool.stop(), or should it happen when the first=
 thread pool object&#39;s destructor is invoked?=C2=A0 Perhaps none of thes=
e questions can be answered until a more comprehensive discussion about Fut=
ure cancellation is explored.</div><div><br></div><div>I can&#39;t find any=
 published papers that really try to comprehensively explore these question=
s.=C2=A0 The closest I found was http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2015/p0008r0.pdf, which discusses various options for thread pool =
shutdown, but discusses it only with &quot;one-way&quot; tasks in mind, not=
 &quot;two-way channel&quot; tasks.</div><div><br></div><div>Are there are =
papers or discussion threads out there that explore this in depth, with the=
 latest Unified Executor/Unified Futures proposal in mind?</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/9eb859b1-7a6b-47d1-b455-7e02d6740225%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9eb859b1-7a6b-47d1-b455-7e02d6740225=
%40isocpp.org</a>.<br />

------=_Part_44367_1406294960.1530047995863--

------=_Part_44366_504920400.1530047995863--

.