async/await doesn’t automatically make things run on another queue/thread. The code you wrote would execute synchronously on the original thread.
-- Adam Kemp > On Sep 19, 2017, at 11:36 PM, Trevör Anne Denise via swift-evolution > <[email protected]> wrote: > >> >> Le 18 sept. 2017 à 18:07, Pierre Habouzit <[email protected]> a écrit : >> >> >> -Pierre >> >>>> On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise >>>> <[email protected]> wrote: >>>> >>>> >>>>> Le 18 sept. 2017 à 07:57, Pierre Habouzit <[email protected]> a écrit : >>>>> >>>>> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> Hello everyone, >>>>> >>>>> I have a few questions about async await in Swift. >>>>> >>>>> Say that you have : >>>>> >>>>> func foo() async { >>>>> print("Hey") >>>>> await bar() >>>>> print("How are you ?") >>>>> } >>>>> >>>>> First of all, am I right to say that : >>>>> 1) If the bar function wasn't an async function, the thread would be >>>>> blocked until bar returns, at this point print("How are you ?") would be >>>>> executed and its only after that that the function calling foo() would >>>>> get back "control" >>>> >>>> I don't think you can quite call await without marking foo() as async (?). >>> >>> >>> Yes, that's what I meant, case one would call foo() without await if it >>> wasn't async. >>> >>> >>>> >>>>> 2) Here (with async bar function), if bar() takes some time to execute, >>>> >>>> Not quite, `await bar()` is afaict syntactic sugar for: >>>> >>>> bar { >>>> printf("How are you ?"); >>>> } >>>> >>>> Where bar used to take a closure before, the compiler is just making it >>>> for you. bar itself will be marked async and will handle its asynchronous >>>> nature e.g. using dispatch or something else entirely. >>>> This has nothing to do with "time". >>> >>> >>> If it's just syntactic sugar then how does this solve this issue mentioned >>> in the concurrency manifesto ? >>> "Beyond being syntactically inconvenient, completion handlers are >>> problematic because their syntax suggests that they will be called on the >>> current queue, but that is not always the case. For example, one of the top >>> recommendations on Stack Overflow is to implement your own custom async >>> operations with code like this (Objective-C syntax):" >> >> "where" things run is not addressed by async/await afaict, but Actors or any >> library-level usage of it. >> > > > So since async await don't have any impact on where things are executed, what > would happen concretely with this code ? > > func slowFunction(_ input: [Int]) async -> [Int] { > var results = [Int]() > for element in input { > results += [someLongComputation(with: element)] > } > return results > } > > beginAsync { > await slowFunction(manyElements) > } > > I didn't specified anything about which queue/thread runs this code, so what > would happen ? Would beginAsync block until slowFunction completes ? > > > Trevör > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
