Talk:cpp/thread/async
Contents |
[edit] Spawning new thread
I think it's wrong to say "async spawns a new thread" with std::launch::async. The specification doesn't mandate it:
"if policy & launch::async is non-zero — calls ... as if in a new thread of execution represented by a thread object with the calls to DECAY_COPY() being evaluated in the thread that called async."
Weasel words mean function may run on a thread pool.
--95.76.33.69 02:10, 29 May 2013 (PDT)
- Good point, someone even implemented launch::async as a pool, as far as I remember. --Cubbi 05:59, 29 May 2013 (PDT)
[edit] It looks like std::async will be deprecated.
It looks like async is being deprecated according to this link. Maybe should mention it in the documentation.
Mikehcox (talk) 16:31, 17 October 2013 (PDT)
[edit] Requirements on arguments to async
Per [futures.async] para 2, F and each Ti in Args shall satisfy MoveConstructible, which was not obvious to me from the semantics of async.
Ruds (talk) 13:48, 11 May 2016 (PDT)
[edit] Deferred destructor
Currently the description of the deferred flag says "the first call to a non-timed wait function on the std::future that async returned to the caller will cause the copy of f to be invoked". ~future says that the destructor will block until the shared state becomes ready. Is there a defined behaviour for when a future is returned by async and destructed without wait being called? --Ybab321 (talk) 06:51, 17 August 2017 (PDT)
- I believe the task just gets canceled (Sean Parent mentions that here too). Not sure how to derived it from the standard wording (the shared state is not ready when that destructor runs.. --Cubbi (talk) 08:14, 17 August 2017 (PDT)
[edit] The documentation seems self-contradictory about async|deferred
It says:
- "If the async flag is set (i.e. (policy & std::launch::async) != 0), then async executes the callable object f on a new thread"
That means that if both async and deferred are set then the "if" condition in the above sentence is true (async is set). That means the docs say it will use a new thread. There is no mention of the possibility of using deferred in this case.
The docs also say:
- "If both the std::launch::async and std::launch::deferred flags are set in policy, it is up to the implementation whether to perform asynchronous execution or lazy evaluation."
That is saying that if both are set, it might not use async. But the first sentence I quote says it will definitely use async in this case.
Which part of the documentation is incorrect?
JacobBurckhardt (talk) 17:13, 9 February 2022 (PST)
- comparing with the standard https://eel.is/c++draft/futures.async#3 , they say at first "if more than one of these conditions applies, the implementation may choose any of the corresponding policies", and then lists the three conditions: async set, deferred set, neither set. Let's see if I can reword it a bit (and add the new detail about the "both" case) --Cubbi (talk) 19:51, 9 February 2022 (PST)
- It seems like the standard has the same contradiction that cppreference.com has. I.e. the standard says "If launch::async is set in policy" which applies even when deferred is also set. I recommend changing that to say "if the launch policy equals std::launch::async" since that phrase means that deferred is not set. My suggested change is consistent with both https://www.cplusplus.com/reference/future/async/ and the exceptions section of https://en.cppreference.com/w/cpp/thread/async which uses the phrase "equals" instead of something like "flag is set". JacobBurckhardt (talk) 13:25, 10 February 2022 (PST)
[edit] UB in future
Could anyone add statements about what Stroustrup wrote: "It is undefined what happens if you try to get() twice. In fact, it is undefined what happens if you try to do any operation except a first get(), a valid(), or a destructor on a future that is not valid(). " ? November 2022
- Those details should be - and are - mentioned in the subpages of std::future --Ybab321 (talk) 13:27, 17 November 2022 (PST)
