Here’s more stuff I found on how this could work. It’s slowly becoming less murky to me.
http://blog.stephencleary.com/2013/11/there-is-no-thread.html <http://blog.stephencleary.com/2013/11/there-is-no-thread.html> -Kenny > On Sep 20, 2017, at 7:19 AM, Adam Kemp via swift-evolution > <[email protected]> wrote: > > 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] <mailto:[email protected]>> wrote: > >>> >>> 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 ? >> >> >> Trevör >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > 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
