Topic: n3777 Depreciating async
Author: fmatthew5876@gmail.com
Date: Tue, 1 Oct 2013 21:04:57 -0700 (PDT)
Raw View
------=_Part_4578_20542302.1380686697858
Content-Type: text/plain; charset=ISO-8859-1
Can anyone enlighten on the story behind this? Whats the story behind
trying to depreciate async? Google returns nothing.
Thanks!
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_4578_20542302.1380686697858
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr">Can anyone enlighten on the story behind this? Whats the story behind trying to depreciate async? Google returns nothing.<div><br></div><div><br></div><div>Thanks!</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_4578_20542302.1380686697858--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 2 Oct 2013 07:08:10 +0300
Raw View
--001a11c25b48a1851904e7ba37b3
Content-Type: text/plain; charset=ISO-8859-1
On 2 October 2013 07:04, <fmatthew5876@gmail.com> wrote:
> Can anyone enlighten on the story behind this? Whats the story behind
> trying to depreciate async? Google returns nothing.
>
>
>
The issue is that future<T> doesn't block in its destructor in general, but
the futures returned by async
do block. This causes problems because the type doesn't really guarantee
either blocking or non-blocking
semantics, which arguably makes composing of libraries harder.
SG1 thought it would be a reasonable remedy to deprecate async and replace
it with
something else that doesn't return futures. The committee disagreed, so the
deprecation didn't
happen.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c25b48a1851904e7ba37b3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 2 October 2013 07:04, <span dir=3D"ltr"><<a href=3D"mailto:f=
matthew5876@gmail.com" target=3D"_blank">fmatthew5876@gmail.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Can anyone enlighten on the=
story behind this? Whats the story behind trying to depreciate async? Goog=
le returns nothing.<div>
<br><br></div></div></blockquote><div><br></div><div>The issue is that futu=
re<T> doesn't block in its destructor in general, but the futures=
returned by async<br>do block. This causes problems because the type doesn=
't really guarantee either blocking or non-blocking<br>
semantics, which arguably makes composing of libraries harder.<br><br>SG1 t=
hought it would be a reasonable remedy to deprecate async and replace it wi=
th<br>something else that doesn't return futures. The committee disagre=
ed, so the deprecation didn't<br>
happen. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c25b48a1851904e7ba37b3--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 2 Oct 2013 10:37:15 +0200
Raw View
--001a113346cefb338304e7bdf919
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Oct 2, 2013 at 6:08 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> SG1 thought it would be a reasonable remedy to deprecate async and replace
> it with
> something else that doesn't return futures.
>
I did not known that part of the story. Was there example of a different
kind of API they are thinking about?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113346cefb338304e7bdf919
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 2, 2013 at 6:08 AM, Ville Voutilainen <span dir="ltr"><<a href="mailto:ville.voutilainen@gmail.com" target="_blank">ville.voutilainen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>SG1 thought it would be a reasonable remedy to deprecate async and replace it with<br>something else that doesn't return futures.</div>
</blockquote></div><br>I did not known that part of the story. Was there example of a different kind of API they are thinking about?<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--001a113346cefb338304e7bdf919--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 2 Oct 2013 11:40:47 +0300
Raw View
--089e011779b59ecd2704e7be060a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 2 October 2013 11:37, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote:
>
> On Wed, Oct 2, 2013 at 6:08 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> SG1 thought it would be a reasonable remedy to deprecate async and
>> replace it with
>> something else that doesn't return futures.
>>
>
> I did not known that part of the story. Was there example of a different
> kind of API they are thinking about?
>
>
>
>
Nothing concrete that I know of, and that was a major reason for committee
opposition
to the deprecation, since there's no replacement and pushing something like
that into
C++14 at the last minute is risky.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e011779b59ecd2704e7be060a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 2 October 2013 11:37, Klaim - Jo=EBl Lamotte <span dir=3D"ltr">&=
lt;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"im"><br><div class=3D"gmail_quote">On Wed, Oct 2, 2013 at 6:0=
8 AM, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.vouti=
lainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>SG1 thought it would be a reasonable re=
medy to deprecate async and replace it with<br>something else that doesn=
9;t return futures.</div>
</blockquote></div><br></div>I did not known that part of the story. Was th=
ere example of a different kind of API they are thinking about?<br></div></=
div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Nothing concrete that =
I know of, and that was a major reason for committee opposition<br>to the d=
eprecation, since there's no replacement and pushing something like tha=
t into<br>
</div><div>C++14 at the last minute is risky. <br></div></div><br></div></d=
iv>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e011779b59ecd2704e7be060a--
.
Author: Matthias Kretz <kretz@compeng.uni-frankfurt.de>
Date: Wed, 02 Oct 2013 10:52:47 +0200
Raw View
--nextPart1482972.R4PqyP05mj
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"
T24gV2VkbmVzZGF5IDAyIE9jdG9iZXIgMjAxMyAwNzowODoxMCBWaWxsZSBWb3V0aWxhaW5lbiB3
cm90ZToKPiBTRzEgdGhvdWdodCBpdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUgcmVtZWR5IHRvIGRl
cHJlY2F0ZSBhc3luYyBhbmQgcmVwbGFjZQo+IGl0IHdpdGgKPiBzb21ldGhpbmcgZWxzZSB0aGF0
IGRvZXNuJ3QgcmV0dXJuIGZ1dHVyZXMuIFRoZSBjb21taXR0ZWUgZGlzYWdyZWVkLCBzbyB0aGUK
PiBkZXByZWNhdGlvbiBkaWRuJ3QgaGFwcGVuLgoKV2VsbCwgZGVwcmVjYXRpb24gZG9lc24ndCBt
YWtlIGFzeW5jIGdvIGF3YXksIHNvIHRoZSBzaXR1YXRpb24gd291bGRuJ3QgaGF2ZSAKY2hhbmdl
ZCBtdWNoIC0gb3RoZXIgdGhhbiBhIGNsZWFyIG1lc3NhZ2UgdGhhdCB0aGUgY3VycmVudCBhc3lu
YyBoYXMgaXNzdWVzLgoKVGhlcmUgYXJlIHBsYW5zIGZvciBhIHJlcGxhY2VtZW50LiBJdCBzaG91
bGQgYXBwZWFyIGluIGEgVFMgYmVmb3JlIEMrKzE3LiBBbmQgCmhvcGVmdWxseSB0aGUgVFMgd2ls
bCBsZWFkIHRvIGEgZ29vZCByZXBsYWNlbWVudCBmb3IgQysrMTcuCgpUaGUgZGVwcmVjYXRpb24g
b2YgYXN5bmMgaW4gQysrMTQgd291bGQsIGluIGEgd2F5LCBoYXZlIGRvY3VtZW50ZWQgdGhlc2Ug
cGxhbnMgCm9mIFNHMSBpbiB0aGUgc3RhbmRhcmQuCgpDaGVlcnMsCglNYXR0aGlhcwotLSAK4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA4pSA
4pSA4pSA4pSACiBEaXBsLi1QaHlzLiBNYXR0aGlhcyBLcmV0egoKIFdlYjogICBodHRwOi8vY29t
cGVuZy51bmktZnJhbmtmdXJ0LmRlLz9ta3JldHoKCiBTSU1EIGVhc3kgYW5kIHBvcnRhYmxlOiBo
dHRwOi8vY29tcGVuZy51bmktZnJhbmtmdXJ0LmRlLz92YwrilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDi
lIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIDilIA=
--nextPart1482972.R4PqyP05mj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEABECAAYFAlJL3t8ACgkQyg4WnCj6OIrEqQCgix+MT54mLjNFsUNjYDJleUj5
qQAAniaE7c8XNvd7jAa5jMNgGrF0Tj4B
=3okO
-----END PGP SIGNATURE-----
--nextPart1482972.R4PqyP05mj--
.
Author: Peter Sommerlad <peter.sommerlad@hsr.ch>
Date: Wed, 2 Oct 2013 11:07:48 +0200
Raw View
IMHO, async() is not broken. It just doesn't allow some use cases some peop=
le thought it would. Async() was incorporated into C++11 as a tool for novi=
ces to use concurrency without the need for low level mechanisms like threa=
d.=20
send from a mobile device.
Prof. Peter Sommerlad
peter.Sommerlad@hsr.ch
+41-79-432 23 32
On 02.10.2013, at 10:52, Matthias Kretz <kretz@compeng.uni-frankfurt.de> wr=
ote:
> On Wednesday 02 October 2013 07:08:10 Ville Voutilainen wrote:
>> SG1 thought it would be a reasonable remedy to deprecate async and repla=
ce
>> it with
>> something else that doesn't return futures. The committee disagreed, so =
the
>> deprecation didn't happen.
>=20
> Well, deprecation doesn't make async go away, so the situation wouldn't h=
ave=20
> changed much - other than a clear message that the current async has issu=
es.
>=20
> There are plans for a replacement. It should appear in a TS before C++17.=
And=20
> hopefully the TS will lead to a good replacement for C++17.
>=20
> The deprecation of async in C++14 would, in a way, have documented these =
plans=20
> of SG1 in the standard.
>=20
> Cheers,
> Matthias
> --=20
> =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80
> Dipl.-Phys. Matthias Kretz
>=20
> Web: http://compeng.uni-frankfurt.de/?mkretz
>=20
> SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
> =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: "R. Martinho Fernandes" <martinho.fernandes@gmail.com>
Date: Wed, 2 Oct 2013 02:35:08 -0700 (PDT)
Raw View
------=_Part_3263_30553633.1380706509174
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, October 2, 2013 11:07:48 AM UTC+2, PeterSommerlad wrote:
>
> IMHO, async() is not broken. It just doesn't allow some use cases some
> people thought it would. Async() was incorporated into C++11 as a tool for
> novices to use concurrency without the need for low level mechanisms like
> thread.
>
This makes no sense. The novice use case *is broken*.
f();
std::async(std::launch::async, g);
h();
// runs sequentially
If a tool intended for novices has the novice use case broken, I'm pretty
sure that makes it broken.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3263_30553633.1380706509174
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 2, 2013 11:07:48 AM UTC+2, PeterSomm=
erlad wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">IMHO, async() is n=
ot broken. It just doesn't allow some use cases some people thought it woul=
d. Async() was incorporated into C++11 as a tool for novices to use concurr=
ency without the need for low level mechanisms like thread.=20
<br></blockquote><div><br>This makes no sense. The novice use case *is brok=
en*.<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>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">async</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">launch</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">async</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> g</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>h</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">// runs sequentially</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><=
br> If a tool intended for novices has the novice use case broken, I'm=
pretty sure that makes it broken.<br></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3263_30553633.1380706509174--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 2 Oct 2013 13:38:59 +0300
Raw View
--f46d043d655757071204e7bfada8
Content-Type: text/plain; charset=ISO-8859-1
On 2 October 2013 12:35, R. Martinho Fernandes <martinho.fernandes@gmail.com
> wrote:
> On Wednesday, October 2, 2013 11:07:48 AM UTC+2, PeterSommerlad wrote:
>>
>> IMHO, async() is not broken. It just doesn't allow some use cases some
>> people thought it would. Async() was incorporated into C++11 as a tool for
>> novices to use concurrency without the need for low level mechanisms like
>> thread.
>>
>
> This makes no sense. The novice use case *is broken*.
>
> f();
> std::async(std::launch::async, g);
> h();
> // runs sequentially
>
> If a tool intended for novices has the novice use case broken, I'm pretty
> sure that makes it broken.
>
>
>
>
Yes, we've heard this argument, and its counter-argument is that having g()
run detached
without anything ever joining it is even more broken.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--f46d043d655757071204e7bfada8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 2 October 2013 12:35, R. Martinho Fernandes <span dir=3D"ltr">&l=
t;<a href=3D"mailto:martinho.fernandes@gmail.com" target=3D"_blank">martinh=
o.fernandes@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im">On Wednes=
day, October 2, 2013 11:07:48 AM UTC+2, PeterSommerlad wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
IMHO, async() is not broken. It just doesn't allow some use cases some =
people thought it would. Async() was incorporated into C++11 as a tool for =
novices to use concurrency without the need for low level mechanisms like t=
hread.=20
<br></blockquote></div><div><br>This makes no sense. The novice use case *i=
s broken*.<br><br><div style=3D"background-color:rgb(250,250,250);border-co=
lor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wo=
rd">
<code><div><span style>f</span><span style=3D"color:#660">();</span><span s=
tyle><br>std</span><span style=3D"color:#660">::</span><span style>async</s=
pan><span style=3D"color:#660">(</span><span style>std</span><span style=3D=
"color:#660">::</span><span style>launch</span><span style=3D"color:#660">:=
:</span><span style>async</span><span style=3D"color:#660">,</span><span st=
yle> g</span><span style=3D"color:#660">);</span><span style><br>
h</span><span style=3D"color:#660">();</span><span style><br></span><span s=
tyle=3D"color:#800">// runs sequentially</span><span style><br></span></div=
></code></div><br>=A0If a tool intended for novices has the novice use case=
broken, I'm pretty sure that makes it broken.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Yes, we've heard t=
his argument, and its counter-argument is that having g() run detached<br>w=
ithout anything ever joining it is even more broken. <br></div></div><br>
</div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d043d655757071204e7bfada8--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 02 Oct 2013 20:22:29 +0800
Raw View
On 10/2/13 6:38 PM, Ville Voutilainen wrote:
> On 2 October 2013 12:35, R. Martinho Fernandes <martinho.fernandes@gmail.com
>>
>> This makes no sense. The novice use case *is broken*.
>>
>> f();
>> std::async(std::launch::async, g);
>> h();
>> // runs sequentially
>>
>> If a tool intended for novices has the novice use case broken, I'm pretty
>> sure that makes it broken.
>>
>>
>>
>>
> Yes, we've heard this argument, and its counter-argument is that having g()
> run detached
> without anything ever joining it is even more broken.
Sounds like a job for my operator void () proposal. Er, proposal for a
proposal. I should write that up.
Really what's broken here is failing to assign the function result to
anything. The proposal addresses similar function results and objects
that cannot go unused.
But, different semantics for different future<> objects is another kind
of brokenness. I don't even see how that's specified, looking now at
N3690. Thanks all for the tip.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 2 Oct 2013 15:30:50 +0300
Raw View
--001a11c227e850e8b804e7c13d2d
Content-Type: text/plain; charset=ISO-8859-1
On 2 October 2013 15:22, David Krauss <potswa@gmail.com> wrote:
>
> But, different semantics for different future<> objects is another kind of
> brokenness. I don't even see how that's specified, looking now at N3690.
> Thanks all for the tip.
See [futures.async]/5, second bullet:
"the associated thread completion synchronizes with (1.10) the return from
the first function that
successfully detects the ready status of the shared state or with the
return from the last function
that releases the shared state, whichever happens first."
The "first function that successfully detects the ready status" is any
function that calls get() or
wait() or any timed waits that don't time out. The "return from the last
function
that releases the shared state" is any function which destroys the last
handle to the shared
state, which is the return value of async itself if the future was never
shared, and the last
shared_future if the future was shared.
That's where the block-on-destruction comes in.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c227e850e8b804e7c13d2d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 2 October 2013 15:22, David Krauss <span dir=3D"ltr"><<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></sp=
an> 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"><br>
But, different semantics for different future<> objects is another ki=
nd of brokenness. I don't even see how that's specified, looking no=
w at N3690. Thanks all for the tip.</blockquote><div><br></div><div>See [fu=
tures.async]/5, second bullet:<br>
"the associated thread completion synchronizes with (1.10) the return =
from the first function that<br>successfully detects the ready status of th=
e shared state or with the return from the last function<br>that releases t=
he shared state, whichever happens first."<br>
<br></div><div>The "first function that successfully detects the ready=
status" is any function that calls get() or<br>wait() or any timed wa=
its that don't time out. The "return from the last function<br>
that releases the shared state" is any function which destroys the las=
t handle to the shared<br>state, which is the return value of async itself =
if the future was never shared, and the last<br>shared_future if the future=
was shared.<br>
<br></div><div>That's where the block-on-destruction comes in.<br></div=
></div></div></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c227e850e8b804e7c13d2d--
.