n3777 Depreciating async

[fmatth...@gmail.com]

Can anyone enlighten on the story behind this? Whats the story behind trying to depreciate async? Google returns nothing.

Thanks!

[Ville Voutilainen]

On 2 October 2013 07:04, <fmatth...@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.

[Klaim - Joël Lamotte]

On Wed, Oct 2, 2013 at 6:08 AM, Ville Voutilainen <ville.vo...@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?

[Ville Voutilainen]

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.

[Matthias Kretz]

On Wednesday 02 October 2013 07:08:10 Ville Voutilainen wrote:
> 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.

Well, deprecation doesn't make async go away, so the situation wouldn't have
changed much - other than a clear message that the current async has issues.

There are plans for a replacement. It should appear in a TS before C++17. And
hopefully the TS will lead to a good replacement for C++17.

The deprecation of async in C++14 would, in a way, have documented these plans
of SG1 in the standard.

Cheers,
Matthias
--
─────────────────────────────────────────────────────────────
Dipl.-Phys. Matthias Kretz

Web: http://compeng.uni-frankfurt.de/?mkretz

SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
─────────────────────────────────────────────────────────────

[Peter Sommerlad]

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.

send from a mobile device.
Prof. Peter Sommerlad
peter.S...@hsr.ch
+41-79-432 23 32

[R. Martinho Fernandes]

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.

[Ville Voutilainen]

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.

[David Krauss]

On 10/2/13 6:38 PM, Ville Voutilainen wrote:
> On 2 October 2013 12:35, R. Martinho Fernandes <martinho....@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.

[Ville Voutilainen]

On 2 October 2013 15:22, David Krauss <pot...@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.