> Le 23 sept. 2017 à 12:23, Trevör Anne Denise via swift-evolution
> <[email protected]> a écrit :
>
>
>> Le 20 sept. 2017 à 21:15, Jean-Daniel <[email protected]
>> <mailto:[email protected]>> a écrit :
>>
>>
>>
>>> Le 20 sept. 2017 à 08:36, Trevör Anne Denise via swift-evolution
>>> <[email protected] <mailto:[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.
>
>
> 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.
}
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
