[swift-evolution] Question about async await

[Wallacy]

Good article. Thanks.
Em sex, 22 de set de 2017 às 14:24, Kenny Leung via swift-evolution <
swift-evolution at 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 at 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 at swift.org> wrote:
>
>
> Le 18 sept. 2017 à 18:07, Pierre Habouzit <pierre at habouzit.net> a écrit :
>
>
> -Pierre
>
> On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <
> trevor.annedenise at icloud.com> wrote:
>
>
> Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre at habouzit.net> a écrit :
>
> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170922/69c360f2/attachment.html>