Good article. Thanks. Em sex, 22 de set de 2017 às 14:24, Kenny Leung via swift-evolution < swift-evolution@swift.org> escreveu:
> 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 > > -Kenny > > > On Sep 20, 2017, at 7:19 AM, Adam Kemp via swift-evolution < > swift-evolution@swift.org> 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 < > swift-evolution@swift.org> wrote: > > > Le 18 sept. 2017 à 18:07, Pierre Habouzit <pie...@habouzit.net> a écrit : > > > -Pierre > > On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise < > trevor.anneden...@icloud.com> wrote: > > > Le 18 sept. 2017 à 07:57, Pierre Habouzit <pie...@habouzit.net> a écrit : > > On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution < > swift-evolution@swift.org> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution