> Le 20 sept. 2017 à 08:36, Trevör Anne Denise via swift-evolution > <[email protected]> a écrit : > >> >> Le 18 sept. 2017 à 18:07, Pierre Habouzit <[email protected] >> <mailto:[email protected]>> a écrit : >> >> >> -Pierre >> >>> On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> >>>> Le 18 sept. 2017 à 07:57, Pierre Habouzit <[email protected] >>>> <mailto:[email protected]>> a écrit : >>>> >>>>> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution >>>>> <[email protected] <mailto:[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 ? >
If I understand correctly, In real code you are not supposed to call beginAsync. It should be wrapped by high level frameworks. GCD may provide a method that take an async lambda as parameter and dispatch it on a the global concurrent queue. Other library may provide entry point that run the code in a private thread pool. This is just a primitive used to support coroutine, but does not define how they are handled.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
