Topic: Cancellation of future continuations
Author: =?UTF-8?Q?Rytis_Karpu=C5=A1ka?= <jauleris@gmail.com>
Date: Tue, 3 Jul 2018 12:56:54 -0700 (PDT)
Raw View
------=_Part_52587_940431483.1530647814941
Content-Type: multipart/alternative;
boundary="----=_Part_52588_1091934794.1530647814942"
------=_Part_52588_1091934794.1530647814942
Content-Type: text/plain; charset="UTF-8"
Hi,
I am new to all of C++ standardization processes so excuse me if these
questions are irrelevant.
Currently there are multiple proposals to standardize std::future
continuations ( http://wg21.link/p1054r0, http://wg21.link/p1053r0,
http://wg21.link/p0701r2, http://wg21.link/p0904r0 ), but cancellation is
only briefly mentioned in one ( http://wg21.link/p1054r0 ) as far as I have
found.
Is cancellation of future continuations relevant to C++ standard library?
Also I would like to get some feedback about the following idea:
Under some circumstances, if some events happen (e.g client closes
connection before response is sent, user cancels some action before it
finishes, etc) it would be helpful to be able to unregister part or all of
the continuation chain. Instead of ( or in addition to ) explicit cancel
method I would like to propose that during registration ( e.g. when calling
..then() ), it would be possible to specify that continuation being
registered should not be invoked if no future further in continuation chain
is waiting for its results. Lets call such continuations strongly dependent
and ones that would be called under same conditions - weakly dependent. In
this case:
auto f = some_future.then(std::future::strongly_dependent, [=](){/* do some
work */});
registered continuation would not be called if f is destructed before
some_future gets its value or exception set.
This would allow to do something like this:
fut = register_some_work().then(
[=](std::future<Data> & d)
{
/* execute work 1 */
return result;
}).then(std::future::strongly_dependent,
[=](std::future<Result> & r)
{
/* execute work 2 */
return result;
}).then(std::future::strongly_dependent,
[=](std::future<Result> & r)
{
/* execute work 3 */
return result;
});
Now if whatever was holding fut stops caring about its result (e.g. client
closes connection therefore response for that client becomes irrelevant) it
might happen that some of the continuations (work 2 and work 3 in the
example) becomes useless (e.g. serializing response for client which has
closed its connection). In this case it would be convenient not to call
those continuations. In the example, if fut gets destructed, then work 3
gets unregistered, because no future is waiting for its result. After work
3 has been unregistered, no future is waiting for work 2 results, so it
also gets unregistered. Work 1 on the other hand keeps being registered as
it is not strongly dependent continuation.
In my opinion this kind of cancellation mechanism would allow to cleanly
release unneeded resources (any objects being held by Callables of
continuations would be destructed) and avoid executing unneeded
continuations under those conditions. Also multiple chained cancellations
can happen naturally (in the example destructing fut would cancel work 3
and work 2).
I have implemented this idea once, but, unfortunately, under NDA. I am
prepared to do some more generic publicly accessible PoC if this gets some
positive feedback :).
--
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/2f8df0e2-27d0-48c3-b9e3-f3e395eedf75%40isocpp.org.
------=_Part_52588_1091934794.1530647814942
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>I am new to all of C++ standardization processe=
s so excuse me if these questions are irrelevant.<br><br>Currently there ar=
e multiple proposals to standardize std::future continuations ( <a href=3D"=
http://wg21.link/p1054r0">http://wg21.link/p1054r0</a>, <a href=3D"http://w=
g21.link/p1053r0">http://wg21.link/p1053r0</a>, <a href=3D"http://wg21.link=
/p0701r2">http://wg21.link/p0701r2</a>, <a href=3D"http://wg21.link/p0904r0=
">http://wg21.link/p0904r0</a> ), but cancellation is only briefly mentione=
d in one ( <a href=3D"http://wg21.link/p1054r0">http://wg21.link/p1054r0</a=
> ) as far as I have found.<br><br>Is cancellation of future continuations =
relevant to C++ standard library?<br><br>Also I would like to get some feed=
back about the following idea:<br><br>Under some circumstances, if some eve=
nts happen (e.g client closes connection before response is sent, user canc=
els some action before it finishes, etc) it would be helpful to be able to =
unregister part or all of the continuation chain. Instead of ( or in additi=
on to ) explicit cancel method I would like to propose that during registra=
tion ( e.g. when calling .then() ), it would be possible to specify that co=
ntinuation being registered should not be invoked if no future further in c=
ontinuation chain is waiting for its results. Lets call such continuations =
strongly dependent and ones that would be called under same conditions - we=
akly dependent. In this case:<br><br><div style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> some_future</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">then</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">future</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">strongly_dependent</span><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;" cla=
ss=3D"styled-by-prettify">[=3D](){</span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">/* do some work */</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">});</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></div></code></div><br>registered conti=
nuation would not be called if f is destructed before some_future gets its =
value or exception set.<br><br>This would allow to do something like this:<=
br><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: br=
eak-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">f=
ut </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> register_some=
_work</span><span style=3D"color: #660;" class=3D"styled-by-prettify">().</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">then</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[=3D](</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">future</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Data</span><span s=
tyle=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: #00=
0;" class=3D"styled-by-prettify"> d</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">/* execute work 1 */</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
result</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}).</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">then</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">future</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">strongly_dependent</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[=3D](</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">future</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Result</span><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: #00=
0;" class=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">/* execute work 2 */</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
result</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}).</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">then</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">future</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">strongly_dependent</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[=3D](</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">future</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">Result</span><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: #00=
0;" class=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">/* execute work 3 */</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
result</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">});</span></div></code></div><br>Now if whatever w=
as holding fut stops caring about its result (e.g. client closes connection=
therefore response for that client becomes irrelevant) it might happen tha=
t some of the continuations (work 2 and work 3 in the example) becomes usel=
ess (e.g. serializing response for client which has closed its connection).=
In this case it would be convenient not to call those continuations. In th=
e example, if fut gets destructed, then work 3 gets unregistered, because n=
o future is waiting for its result. After work 3 has been unregistered, no =
future is waiting for work 2 results, so it also gets unregistered. Work 1 =
on the other hand keeps being registered as it is not strongly dependent co=
ntinuation.<br><br>In my opinion this kind of cancellation mechanism would =
allow to cleanly release unneeded resources (any objects being held by Call=
ables of continuations would be destructed) and avoid executing unneeded co=
ntinuations under those conditions. Also multiple chained cancellations can=
happen naturally (in the example destructing fut would cancel work 3 and w=
ork 2).<br><br>I have implemented this idea once, but, unfortunately, under=
NDA. I am prepared to do some more generic publicly accessible PoC if this=
gets some positive feedback :).<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2f8df0e2-27d0-48c3-b9e3-f3e395eedf75%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2f8df0e2-27d0-48c3-b9e3-f3e395eedf75=
%40isocpp.org</a>.<br />
------=_Part_52588_1091934794.1530647814942--
------=_Part_52587_940431483.1530647814941--
.
Author: Sergey Vidyuk <sir.vestnik@gmail.com>
Date: Wed, 4 Jul 2018 00:57:08 -0700 (PDT)
Raw View
------=_Part_57101_1102251612.1530691028531
Content-Type: multipart/alternative;
boundary="----=_Part_57102_2001477809.1530691028532"
------=_Part_57102_2001477809.1530691028532
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 4 =D0=B8=D1=8E=D0=BB=D1=8F 2018 =D0=B3., 2:=
56:55 UTC+7 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=
=BB=D1=8C Rytis Karpu=C5=A1ka =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
> I have implemented this idea once, but, unfortunately, under NDA. I am=20
> prepared to do some more generic publicly accessible PoC if this gets som=
e=20
> positive feedback :).
>
I have implementation of similar idea under public license here:=20
https://github.com/VestniK/portable_concurrency My implementation follows=
=20
your `std::future::strongly_dependent` policy by default and provides=20
`future::detach` method to prevent work cancelation by `future` destructor.
=20
Sergey Vidyuk
--=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/528cf498-cb7b-4313-aece-e90df59448aa%40isocpp.or=
g.
------=_Part_57102_2001477809.1530691028532
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 4 =D0=B8=D1=8E=D0=BB=D1=8F=
2018 =D0=B3., 2:56:55 UTC+7 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=
=B0=D1=82=D0=B5=D0=BB=D1=8C Rytis Karpu=C5=A1ka =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">I have implemented this idea once, but, unfortunately, under NDA. =
I am prepared to do some more generic publicly accessible PoC if this gets =
some positive feedback :).<br></div></blockquote><div><br></div><div>I have=
implementation of similar idea under public license here: https://github.c=
om/VestniK/portable_concurrency My implementation follows your `<code><span=
style=3D"color:#000">std</span><span style=3D"color:#660">::</span><span s=
tyle=3D"color:#000">future</span><span style=3D"color:#660">::</span><span =
style=3D"color:#000">strongly_<wbr>dependent</span><span style=3D"color:#66=
0"></span></code>` policy by default and provides `future::detach` method t=
o prevent work cancelation by `future` destructor.</div><div>=C2=A0<br></di=
v><div>Sergey Vidyuk<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/528cf498-cb7b-4313-aece-e90df59448aa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/528cf498-cb7b-4313-aece-e90df59448aa=
%40isocpp.org</a>.<br />
------=_Part_57102_2001477809.1530691028532--
------=_Part_57101_1102251612.1530691028531--
.
Author: =?UTF-8?Q?Rytis_Karpu=C5=A1ka?= <jauleris@gmail.com>
Date: Wed, 4 Jul 2018 12:44:19 -0700 (PDT)
Raw View
------=_Part_62141_1197263598.1530733460025
Content-Type: multipart/alternative;
boundary="----=_Part_62142_203704062.1530733460025"
------=_Part_62142_203704062.1530733460025
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
2018 m. liepa 4 d., tre=C4=8Diadienis 10:57:08 UTC+3, Sergey Vidyuk ra=C5=
=A1=C4=97:
>
> =D1=81=D1=80=D0=B5=D0=B4=D0=B0, 4 =D0=B8=D1=8E=D0=BB=D1=8F 2018 =D0=B3., =
2:56:55 UTC+7 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=
=D0=BB=D1=8C Rytis Karpu=C5=A1ka =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB=
:
>
>> I have implemented this idea once, but, unfortunately, under NDA. I am=
=20
>> prepared to do some more generic publicly accessible PoC if this gets so=
me=20
>> positive feedback :).
>>
>
> I have implementation of similar idea under public license here:=20
> https://github.com/VestniK/portable_concurrency My implementation follows=
=20
> your `std::future::strongly_dependent` policy by default and provides=20
> `future::detach` method to prevent work cancelation by `future` destructo=
r.
> =20
> Sergey Vidyuk
>
Nice, I will check this out :).=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/534b42ee-ddc4-4fe4-9ecd-06a18f8fce88%40isocpp.or=
g.
------=_Part_62142_203704062.1530733460025
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">2018 m. liepa 4 d., tre=C4=8Diadienis 10:57:08 UTC+3, Serg=
ey Vidyuk ra=C5=A1=C4=97:<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">=D1=81=D1=80=D0=B5=D0=B4=D0=B0, 4 =D0=B8=D1=8E=D0=BB=D1=8F 2018=
=D0=B3., 2:56:55 UTC+7 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=
=82=D0=B5=D0=BB=D1=8C Rytis Karpu=C5=A1ka =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=
=B0=D0=BB:<br><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">I ha=
ve implemented this idea once, but, unfortunately, under NDA. I am prepared=
to do some more generic publicly accessible PoC if this gets some positive=
feedback :).<br></div></blockquote><div><br></div><div>I have implementati=
on of similar idea under public license here: <a href=3D"https://github.com=
/VestniK/portable_concurrency" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub=
..com%2FVestniK%2Fportable_concurrency\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNFl5lhNRyyBIph1GaT1li6TeJvrDQ';return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FVestniK%2Fpo=
rtable_concurrency\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFl5lhNRyyBIph1Ga=
T1li6TeJvrDQ';return true;">https://github.com/VestniK/<wbr>portable_co=
ncurrency</a> My implementation follows your `<code><span style=3D"color:#0=
00">std</span><span style=3D"color:#660">::</span><span style=3D"color:#000=
">future</span><span style=3D"color:#660">::</span><span style=3D"color:#00=
0">strongly_<wbr>dependent</span><span style=3D"color:#660"></span></code>`=
policy by default and provides `future::detach` method to prevent work can=
celation by `future` destructor.</div><div>=C2=A0<br></div><div>Sergey Vidy=
uk<br></div></div></blockquote><div><br></div><div>Nice, I will check this =
out :). <br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/534b42ee-ddc4-4fe4-9ecd-06a18f8fce88%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/534b42ee-ddc4-4fe4-9ecd-06a18f8fce88=
%40isocpp.org</a>.<br />
------=_Part_62142_203704062.1530733460025--
------=_Part_62141_1197263598.1530733460025--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Wed, 4 Jul 2018 15:38:09 -0700 (PDT)
Raw View
------=_Part_6057_388366433.1530743889765
Content-Type: multipart/alternative;
boundary="----=_Part_6058_1901283477.1530743889765"
------=_Part_6058_1901283477.1530743889765
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tuesday, July 3, 2018 at 12:56:55 PM UTC-7, Rytis Karpu=C5=A1ka wrote:
>
>
> Currently there are multiple proposals to standardize std::future=20
> continuations ( http://wg21.link/p1054r0, http://wg21.link/p1053r0,=20
> http://wg21.link/p0701r2, http://wg21.link/p0904r0 ), but cancellation is=
=20
> only briefly mentioned in one ( http://wg21.link/p1054r0=20
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fwg21.link%2Fp1054r0&sa=3DD&sn=
tz=3D1&usg=3DAFQjCNHtaIvler9y4imNIziJ9CeNHTpCDA>=20
> ) as far as I have found.
>
> Is cancellation of future continuations relevant to C++ standard library?
>
I don't know about the Committee, but the idea in general has been=20
implemented at least a few times.
- Sean Parent's "Better Code: Concurrency" develops the idea of a=20
cancellable task graph. He's got too many different YouTube versions so I=
=20
don't know which one is the best to recommend, but=20
e.g. https://www.youtube.com/watch?v=3DQIHy8pXbneI
- My CppCon 2015 talk was essentially based on Sean's=20
ideas: https://www.youtube.com/watch?v=3DjfDRgnxDe7o&t=3D38m50s
Incidentally, I call it "work-dropping" (analogous to "work-stealing", in=
=20
that it operates on the same task granularity). If you say "cancellation,"=
=20
people might confuse it with pthread_cancel=20
<http://man7.org/linux/man-pages/man3/pthread_cancel.3.html>, which means=
=20
much more destructively "interrupting" another thread before it's finished=
=20
even its current granule of work. I can't tell if P1054R0's thing was=20
intended to mean work-dropping or interrupting or possibly both.
I made a toy implementation for my talk, but nothing that anyone should=20
actually try to use.
My understanding is that Sean Parent has implemented the real deal at least=
=20
once (for Adobe?) and maybe several times.
I don't know of any public implementation, but then I've never looked.
I know that Folly futures do *not* do "work-dropping."
=E2=80=93Arthur
--=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/ff7079dc-3168-4d6d-92ff-43a3cdaaa145%40isocpp.or=
g.
------=_Part_6058_1901283477.1530743889765
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 3, 2018 at 12:56:55 PM UTC-7, Rytis Karpu=
=C5=A1ka 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>Currently there are multiple proposals to standardize std::future con=
tinuations ( <a href=3D"http://wg21.link/p1054r0" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dht=
tp%3A%2F%2Fwg21.link%2Fp1054r0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHtaI=
vler9y4imNIziJ9CeNHTpCDA';return true;" onclick=3D"this.href=3D'htt=
p://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2Fp1054r0\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNHtaIvler9y4imNIziJ9CeNHTpCDA';return true;">h=
ttp://wg21.link/p1054r0</a>, <a href=3D"http://wg21.link/p1053r0" target=3D=
"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fwg21.link%2Fp1053r0\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNFuBYOF95B_ybsgEU1lNC0wR_Cbvg';return true;" onclick=3D"this=
..href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2Fp1053r=
0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFuBYOF95B_ybsgEU1lNC0wR_Cbvg'=
;return true;">http://wg21.link/p1053r0</a>, <a href=3D"http://wg21.link/p0=
701r2" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'h=
ttp://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2Fp0701r2\x26sa\x3dD\x=
26sntz\x3d1\x26usg\x3dAFQjCNE5RQOYZD-dX625Qz154x6KBGrQyQ';return true;"=
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg=
21.link%2Fp0701r2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE5RQOYZD-dX625Qz1=
54x6KBGrQyQ';return true;">http://wg21.link/p0701r2</a>, <a href=3D"htt=
p://wg21.link/p0904r0" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2Fp090=
4r0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHfKXVxbmbiDsfSQeAtGdPE4EaRkQ=
9;;return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3=
dhttp%3A%2F%2Fwg21.link%2Fp0904r0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
fKXVxbmbiDsfSQeAtGdPE4EaRkQ';return true;">http://wg21.link/p0904r0</a>=
), but cancellation is only briefly mentioned in one ( <a href=3D"http://w=
ww.google.com/url?q=3Dhttp%3A%2F%2Fwg21.link%2Fp1054r0&sa=3DD&sntz=
=3D1&usg=3DAFQjCNHtaIvler9y4imNIziJ9CeNHTpCDA" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fwg21.link%2Fp1054r0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHta=
Ivler9y4imNIziJ9CeNHTpCDA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2Fp1054r0\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNHtaIvler9y4imNIziJ9CeNHTpCDA';return true;">=
http://wg21.link/p1054r0</a> ) as far as I have found.<br><br>Is cancellati=
on of future continuations relevant to C++ standard library?<br></div></blo=
ckquote><div><br></div><div>I don't know about the Committee, but the i=
dea in general has been implemented at least a few times.</div><div>- Sean =
Parent's "Better Code: Concurrency" develops the idea of a ca=
ncellable task graph. He's got too many different YouTube versions so I=
don't know which one is the best to recommend, but e.g.=C2=A0https://w=
ww.youtube.com/watch?v=3DQIHy8pXbneI</div><div>- My CppCon 2015 talk was es=
sentially based on Sean's ideas:=C2=A0https://www.youtube.com/watch?v=
=3DjfDRgnxDe7o&t=3D38m50s</div><div><br></div><div>Incidentally, I call=
it "work-dropping" (analogous to "work-stealing", in t=
hat it operates on the same task granularity). =C2=A0If you say "cance=
llation," people might confuse it with <a href=3D"http://man7.org/linu=
x/man-pages/man3/pthread_cancel.3.html">pthread_cancel</a>, which means muc=
h more destructively "interrupting" another thread before it'=
s finished even its current granule of work. =C2=A0I can't tell if P105=
4R0's thing was intended to mean work-dropping or interrupting or possi=
bly both.</div><div><br></div><div>I made a toy implementation for my talk,=
but nothing that anyone should actually try to use.</div><div>My understan=
ding is that Sean Parent has implemented the real deal at least once (for A=
dobe?) and maybe several times.</div><div>I don't know of any public im=
plementation, but then I've never looked.</div><div>I know that Folly f=
utures do <i>not</i> do "work-dropping."</div><div><br></div><div=
>=E2=80=93Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ff7079dc-3168-4d6d-92ff-43a3cdaaa145%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ff7079dc-3168-4d6d-92ff-43a3cdaaa145=
%40isocpp.org</a>.<br />
------=_Part_6058_1901283477.1530743889765--
------=_Part_6057_388366433.1530743889765--
.
Author: Lee Howes <xrikcus@gmail.com>
Date: Thu, 5 Jul 2018 16:50:32 -0700
Raw View
--00000000000086134d057049362e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
In P1054 we were careful to not require cancellation in the future concept,
because we are split on whether we actually want cancellation, and at this
stage we do not want to enforce what a given future provides semantically.
Cancellation is, after all, fundamentally optimistic. We could say that
futures cancel and cancellation for my future implementation is a no-op,
which would be pointless.
What we did instead was to define the promise contract. The current
executors proposal defines no way to interact between different future
types, owned by different executors. The promise contract is there to
support that - to ask an executor for a "promise" that my future type can
trigger and that signals some future type that that executor can use in
work chaining. If cancellation is ever to work it is important that the
cancellation request can bridge those futures as well, and so we added the
ability to construct a promise contract with cancellation support. That
means that my future can create a cancellation callback and pass it to your
executor - if your executor supports cancellation, and the first task in
its work chain is cancelled then it can call my callback and I can decide
what I do with that, potentially propagating cancellation up through my
work chain. Semantically that bridge means something like "I do not care if
you never satisfy this promise, if that allows you to not run work then
please feel free to not run work".
The goal here was to provide the minimal support that allows us to
implement cancellation and not trap ourselves in a world of futures that do
not support cancellation, without actually requiring specific cancellation
semantics.
folly futures do not do work dropping, except when they do. Deferred work
is dropped if there is no chained executor for that work to be enqueued on,
because there is semantically no practical alternative to cancellation in
that case.
On 4 July 2018 at 15:38, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> On Tuesday, July 3, 2018 at 12:56:55 PM UTC-7, Rytis Karpu=C5=A1ka wrote:
>>
>>
>> Currently there are multiple proposals to standardize std::future
>> continuations ( http://wg21.link/p1054r0, http://wg21.link/p1053r0,
>> http://wg21.link/p0701r2, http://wg21.link/p0904r0 ), but cancellation
>> is only briefly mentioned in one ( http://wg21.link/p1054r0
>> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fwg21.link%2Fp1054r0&sa=3DD&s=
ntz=3D1&usg=3DAFQjCNHtaIvler9y4imNIziJ9CeNHTpCDA>
>> ) as far as I have found.
>>
>> Is cancellation of future continuations relevant to C++ standard library=
?
>>
>
> I don't know about the Committee, but the idea in general has been
> implemented at least a few times.
> - Sean Parent's "Better Code: Concurrency" develops the idea of a
> cancellable task graph. He's got too many different YouTube versions so I
> don't know which one is the best to recommend, but e.g.
> https://www.youtube.com/watch?v=3DQIHy8pXbneI
> - My CppCon 2015 talk was essentially based on Sean's ideas:
> https://www.youtube.com/watch?v=3DjfDRgnxDe7o&t=3D38m50s
>
> Incidentally, I call it "work-dropping" (analogous to "work-stealing", in
> that it operates on the same task granularity). If you say "cancellation=
,"
> people might confuse it with pthread_cancel
> <http://man7.org/linux/man-pages/man3/pthread_cancel.3.html>, which means
> much more destructively "interrupting" another thread before it's finishe=
d
> even its current granule of work. I can't tell if P1054R0's thing was
> intended to mean work-dropping or interrupting or possibly both.
>
> I made a toy implementation for my talk, but nothing that anyone should
> actually try to use.
> My understanding is that Sean Parent has implemented the real deal at
> least once (for Adobe?) and maybe several times.
> I don't know of any public implementation, but then I've never looked.
> I know that Folly futures do *not* do "work-dropping."
>
> =E2=80=93Arthur
>
> --
> 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/ff7079dc-3168-4d6d-
> 92ff-43a3cdaaa145%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ff7079dc-31=
68-4d6d-92ff-43a3cdaaa145%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=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/CAJH_FNUoPXZMBJ08jgpzvgg9HTX%2B2D9c2QeTuWhzMWcdd=
ehFrQ%40mail.gmail.com.
--00000000000086134d057049362e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In P1054 we were careful to not require cancellation in th=
e future concept, because we are split on whether we actually want cancella=
tion, and at this stage we do not want to enforce what a given future provi=
des semantically. Cancellation is, after all, fundamentally optimistic. We =
could say that futures cancel and cancellation for my future implementation=
is a no-op, which would be pointless.<div><br></div><div>What we did inste=
ad was to define the promise contract. The current executors proposal defin=
es no way to interact between different future types, owned by different ex=
ecutors. The promise contract is there to support that - to ask an executor=
for a "promise" that my future type can trigger and that signals=
some future type that that executor can use in work chaining. If cancellat=
ion is ever to work it is important that the cancellation request can bridg=
e those futures as well, and so we added the ability to construct a promise=
contract with cancellation support. That means that my future can create a=
cancellation callback and pass it to your executor - if your executor supp=
orts cancellation, and the first task in its work chain is cancelled then i=
t can call my callback and I can decide what I do with that, potentially pr=
opagating cancellation up through my work chain. Semantically that bridge m=
eans something like "I do not care if you never satisfy this promise, =
if that allows you to not run work then please feel free to not run work&qu=
ot;.</div><div><br></div><div>The goal here was to provide the minimal supp=
ort that allows us to implement cancellation and not trap ourselves in a wo=
rld of futures that do not support cancellation, without actually requiring=
specific cancellation semantics.</div><div><br></div><div>folly futures do=
not do work dropping, except when they do. Deferred work is dropped if the=
re is no chained executor for that work to be enqueued on, because there is=
semantically no practical alternative to cancellation in that case.</div><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 4 July 20=
18 at 15:38, Arthur O'Dwyer <span dir=3D"ltr"><<a href=3D"mailto:art=
hur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>>=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span cla=
ss=3D"">On Tuesday, July 3, 2018 at 12:56:55 PM UTC-7, Rytis Karpu=C5=A1ka =
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>Currentl=
y there are multiple proposals to standardize std::future continuations ( <=
a href=3D"http://wg21.link/p1054r0" rel=3D"nofollow" target=3D"_blank">http=
://wg21.link/p1054r0</a>, <a href=3D"http://wg21.link/p1053r0" rel=3D"nofol=
low" target=3D"_blank">http://wg21.link/p1053r0</a>, <a href=3D"http://wg21=
..link/p0701r2" rel=3D"nofollow" target=3D"_blank">http://wg21.link/p0701r2<=
/a>, <a href=3D"http://wg21.link/p0904r0" rel=3D"nofollow" target=3D"_blank=
">http://wg21.link/p0904r0</a> ), but cancellation is only briefly mentione=
d in one ( <a href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fwg21.link%=
2Fp1054r0&sa=3DD&sntz=3D1&usg=3DAFQjCNHtaIvler9y4imNIziJ9CeNHTp=
CDA" rel=3D"nofollow" target=3D"_blank">http://wg21.link/p1054r0</a> ) as f=
ar as I have found.<br><br>Is cancellation of future continuations relevant=
to C++ standard library?<br></div></blockquote><div><br></div></span><div>=
I don't know about the Committee, but the idea in general has been impl=
emented at least a few times.</div><div>- Sean Parent's "Better Co=
de: Concurrency" develops the idea of a cancellable task graph. He'=
;s got too many different YouTube versions so I don't know which one is=
the best to recommend, but e.g.=C2=A0<a href=3D"https://www.youtube.com/wa=
tch?v=3DQIHy8pXbneI" target=3D"_blank">https://www.youtube.com/<wbr>watch?v=
=3DQIHy8pXbneI</a></div><div>- My CppCon 2015 talk was essentially based on=
Sean's ideas:=C2=A0<a href=3D"https://www.youtube.com/watch?v=3DjfDRgn=
xDe7o&t=3D38m50s" target=3D"_blank">https://www.youtube.<wbr>com/watch?=
v=3DjfDRgnxDe7o&t=3D<wbr>38m50s</a></div><div><br></div><div>Incidental=
ly, I call it "work-dropping" (analogous to "work-stealing&q=
uot;, in that it operates on the same task granularity).=C2=A0 If you say &=
quot;cancellation," people might confuse it with <a href=3D"http://man=
7.org/linux/man-pages/man3/pthread_cancel.3.html" target=3D"_blank">pthread=
_cancel</a>, which means much more destructively "interrupting" a=
nother thread before it's finished even its current granule of work.=C2=
=A0 I can't tell if P1054R0's thing was intended to mean work-dropp=
ing or interrupting or possibly both.</div><div><br></div><div>I made a toy=
implementation for my talk, but nothing that anyone should actually try to=
use.</div><div>My understanding is that Sean Parent has implemented the re=
al deal at least once (for Adobe?) and maybe several times.</div><div>I don=
't know of any public implementation, but then I've never looked.</=
div><div>I know that Folly futures do <i>not</i> do "work-dropping.&qu=
ot;</div><div><br></div><div>=E2=80=93Arthur</div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ff7079dc-3168-4d6d-92ff-43a3cdaaa145%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/ff70=
79dc-3168-4d6d-<wbr>92ff-43a3cdaaa145%40isocpp.org</a><wbr>.<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" 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_FNUoPXZMBJ08jgpzvgg9HTX%2B2D9c2Q=
eTuWhzMWcddehFrQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAJH_FNUoPXZMBJ=
08jgpzvgg9HTX%2B2D9c2QeTuWhzMWcddehFrQ%40mail.gmail.com</a>.<br />
--00000000000086134d057049362e--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Fri, 6 Jul 2018 01:51:30 -0700 (PDT)
Raw View
------=_Part_77810_1339607449.1530867090980
Content-Type: multipart/alternative;
boundary="----=_Part_77811_1241751921.1530867090980"
------=_Part_77811_1241751921.1530867090980
Content-Type: text/plain; charset="UTF-8"
On Friday, July 6, 2018 at 12:50:35 AM UTC+1, Lee Howes wrote:
>
> In P1054 we were careful to not require cancellation in the future
> concept, because we are split on whether we actually want cancellation, and
> at this stage we do not want to enforce what a given future provides
> semantically. Cancellation is, after all, fundamentally optimistic. We
> could say that futures cancel and cancellation for my future implementation
> is a no-op, which would be pointless.
>
In my experience cancellation is required to implement efficient (as in
non-allocating) wait_any (for threads or coroutines) as any continuation
required by the future can be stack allocated and needs to be destroyed
after at least one of the futures is ready. This also requires
non-allocating continuation support though.
-- 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/34e839c9-e878-40ea-9058-4597acab628d%40isocpp.org.
------=_Part_77811_1241751921.1530867090980
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, July 6, 2018 at 12:50:35 AM UTC+1, Lee Howes wr=
ote:<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">In P1054 =
we were careful to not require cancellation in the future concept, because =
we are split on whether we actually want cancellation, and at this stage we=
do not want to enforce what a given future provides semantically. Cancella=
tion is, after all, fundamentally optimistic. We could say that futures can=
cel and cancellation for my future implementation is a no-op, which would b=
e pointless.</div></blockquote><div><br>In my experience cancellation is re=
quired to implement efficient (as in non-allocating) wait_any (for threads =
or coroutines) as any continuation required by the future can be stack allo=
cated and needs to be destroyed after at least one of the futures is ready.=
This also requires non-allocating continuation support though.</div><br>--=
gpd<br></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/34e839c9-e878-40ea-9058-4597acab628d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/34e839c9-e878-40ea-9058-4597acab628d=
%40isocpp.org</a>.<br />
------=_Part_77811_1241751921.1530867090980--
------=_Part_77810_1339607449.1530867090980--
.