[swift-evolution] Question about async await
Jean-Daniel
mailing at xenonium.com
Mon Sep 25 17:03:53 CDT 2017
> Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution at swift.org> a écrit :
>
>> On Sep 25, 2017, at 3:14 PM, Jean-Daniel via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> Le 25 sept. 2017 à 18:54, Trevör Anne Denise via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>>
>>>>
>>>> Le 25 sept. 2017 à 13:33, Trevör ANNE DENISE <trevor.annedenise at icloud.com <mailto:trevor.annedenise at icloud.com>> a écrit :
>>>>
>>>>
>>>> Le 25 sept. 2017 à 11:55, Thomas <tclementdev at free.fr <mailto:tclementdev at free.fr>> a écrit :
>>>>
>>>>>
>>>>>> On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>
>>>>>>
>>>>>>> Le 24 sept. 2017 à 12:00, Jean-Daniel <mailing at xenonium.com <mailto:mailing at xenonium.com>> a écrit :
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Le 23 sept. 2017 à 12:23, Trevör Anne Denise via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>>>>>>>
>>>>>>>>
>>>>>>>>> Le 20 sept. 2017 à 21:15, Jean-Daniel <mailing at xenonium.com <mailto:mailing at xenonium.com>> a écrit :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Le 20 sept. 2017 à 08:36, Trevör Anne Denise via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Le 18 sept. 2017 à 18:07, Pierre Habouzit <pierre at habouzit.net <mailto:pierre at habouzit.net>> a écrit :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -Pierre
>>>>>>>>>>>
>>>>>>>>>>>> On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise at icloud.com <mailto:trevor.annedenise at icloud.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre at habouzit.net <mailto: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 <mailto: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 ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you everyone, I understand it better now, I still have some questions tough.
>>>>>>>> Just to be sure that I am understanding this correctly, if you some async function and it suspends itself, then your current async function making this call will also suspend itself, right ?
>>>>>>>>
>>>>>>>> Also, I understand how suspendAsync will be used to warp current callback based functions into async/await friendly functions and in this case :
>>>>>>>> func getStuff() async -> Stuff {
>>>>>>>> return await suspendAsync { continuation in
>>>>>>>> getStuff(completion: continuation)
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> Here, I understand how the function controls where continuation is executed, but how would you write an API supporting async/await from scratch ?
>>>>>>>>
>>>>>>>> Say that I want to build an async function that downloads data, with libdispatch I could do :
>>>>>>>> func dowloadSomething() {
>>>>>>>> await someBackgroundQueue.asyncCorountine()
>>>>>>>> // Here I would put my code for downloading data
>>>>>>>>
>>>>>>>> // But would I have to put anything after that to choose where to execute the continuation ? DispatchQueue.main.syncCorountine() maybe ?
>>>>>>>> }
>>>>>>>
>>>>>>> The high level stuff is not designed yet, and how to specify the continuation target queue/thread is not defined at this point.
>>>>>>>
>>>>>>> Your code will probably be something like
>>>>>>>
>>>>>>> Dispatch.startAync {
>>>>>>> val stuff = await downloadStuff()
>>>>>>> // do something with stuff once it is done.
>>>>>>> }
>>>>>>
>>>>>>
>>>>>> Do you mean that the API to execute the continuation back on its original thread ? (avoiding shared mutable state)
>>>>>
>>>>> I think you have to do something like this:
>>>>>
>>>>> func async doSomethingInBackground(callbackQueue: DispatchQueue) -> SomeResult {
>>>>> await someBackgroundQueue.asyncCorountine()
>>>>>
>>>>> // Here I would put my (potentially lengthy) background code.
>>>>>
>>>>> // Jump on the requested callback queue.
>>>>> await callbackQueue.asyncCoroutine()
>>>>>
>>>>> // Return result (if any).
>>>>> return result
>>>>> }
>>>>>
>>>>>
>>>>> Thomas
>>>>>
>>>>
>>>> I hope this will be handled automatically the compiler tough !
>>>
>>>
>>>
>>>
>>> Did anyone started to sketch a design for how giving back control to the calling queue will work ?
>>>
>>> Would it make any sense to limit asyncCorountine() to the scope of the function where it gets called and implicitly "hop back" to the calling queue so that no shared mutable state issues arise ?
>>
>> No. Async methods are not require to be dispatched on a queue
>
> This doesn't have to be the case, actually. The intrinsics as Chris described them wouldn't be sufficient, but you could require a "current queue" to be provided when kicking off an async function from scratch, as well as any other "async-local" context information you wanted (e.g. QoS and the other things that Dispatch tracks with attributes/flags that are generally supposed to persist across an entire async operation).
>
My response was about the ‘implicitly’ part. I hope we will get a rich API that let us specify return queue, QoS and more, but how do you plan to fulfill the « current queue » requirement implicitly ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170926/d452ae8e/attachment.html>
More information about the swift-evolution
mailing list