------=_Part_559_1891931068.1494882531766
Content-Type: multipart/alternative;
 boundary="----=_Part_560_1963756894.1494882531766"

------=_Part_560_1963756894.1494882531766
Content-Type: text/plain; charset="UTF-8"

I recently stumbled upon a post that talked about how futures are slow
because get() blocks
(https://isocpp.org/blog/2016/07/cppcon-2015-completion-t-improving-the-future-t-with-monads-travis-gockel)
even when you don't need to block.  For example in a callback attached with
..then()

auto future = async(...);
future.then([](std::future<int> future) {
    future.get(); // unnecessary locking
});

A lot of future libraries out there have a different versions of then to
avoid this problem (for example Facebook's futures and in the
aforementioned post).  Why not have a version of get() that does no locking
or atomic loads?  And assume that the user will only call this within a
callback attached with .then()?

auto future = async(...);
future.then([](std::future<int> future) {
    future.fetch(); // no unnecessary locking
});

--
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/1ed6e69f-3f75-4084-be44-54af105e0cf8%40isocpp.org.

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

<div dir=3D"ltr">I recently stumbled upon a post that talked about how futu=
res are slow because <font face=3D"courier new, monospace">get()</font> blo=
cks (https://isocpp.org/blog/2016/07/cppcon-2015-completion-t-improving-the=
-future-t-with-monads-travis-gockel) even when you don&#39;t need to block.=
 =C2=A0For example in a callback attached with <font face=3D"courier new, m=
onospace">.then()</font><div><br></div><div><font face=3D"courier new, mono=
space">auto future =3D async(...);</font></div><div><font face=3D"courier n=
ew, monospace">future.then([](std::future&lt;int&gt; future) {</font></div>=
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 future.get(); //=
=C2=A0unnecessary=C2=A0locking</font></div><div><font face=3D"courier new, =
monospace">});</font></div><div><font face=3D"courier new, monospace"><br><=
/font></div><div><font face=3D"arial, sans-serif">A lot of </font><font fac=
e=3D"courier new, monospace">future</font><font face=3D"arial, sans-serif">=
 libraries out there have a different versions of then to avoid this proble=
m (for example Facebook&#39;s futures and in the aforementioned post). =C2=
=A0Why not have a version of </font><font face=3D"courier new, monospace">g=
et()</font><font face=3D"arial, sans-serif">=C2=A0that does no locking or a=
tomic loads? =C2=A0And assume that the user will only call this within a ca=
llback attached with </font><font face=3D"courier new, monospace">.then()</=
font><font face=3D"arial, sans-serif">?</font></div><div><font face=3D"aria=
l, sans-serif"><br></font></div><div><div><font face=3D"courier new, monosp=
ace">auto future =3D async(...);</font></div><div><font face=3D"courier new=
, monospace">future.then([](std::future&lt;int&gt; future) {</font></div><d=
iv><font face=3D"courier new, monospace">=C2=A0 =C2=A0 future.fetch(); // n=
o unnecessary=C2=A0locking</font></div><div><font face=3D"courier new, mono=
space">});</font></div></div><div><font face=3D"courier new, monospace"><br=
></font></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/1ed6e69f-3f75-4084-be44-54af105e0cf8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1ed6e69f-3f75-4084-be44-54af105e0cf8=
%40isocpp.org</a>.<br />

------=_Part_560_1963756894.1494882531766--

------=_Part_559_1891931068.1494882531766--

.