> Le 24 sept. 2017 à 12:00, Jean-Daniel <mail...@xenonium.com> a écrit :
>
>
>
>> Le 23 sept. 2017 à 12:23, Trevör Anne Denise via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>
>>
>>> Le 20 sept. 2017 à 21:15, Jean-Daniel <mail...@xenonium.com
>>> <mailto:mail...@xenonium.com>> a écrit :
>>>
>>>
>>>
>>>> Le 20 sept. 2017 à 08:36, Trevör Anne Denise via swift-evolution
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>>>>
>>>>>
>>>>> Le 18 sept. 2017 à 18:07, Pierre Habouzit <pie...@habouzit.net
>>>>> <mailto:pie...@habouzit.net>> a écrit :
>>>>>
>>>>>
>>>>> -Pierre
>>>>>
>>>>>> On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise
>>>>>> <trevor.anneden...@icloud.com <mailto:trevor.anneden...@icloud.com>>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> Le 18 sept. 2017 à 07:57, Pierre Habouzit <pie...@habouzit.net
>>>>>>> <mailto:pie...@habouzit.net>> a écrit :
>>>>>>>
>>>>>>>> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution
>>>>>>>> <swift-evolution@swift.org <mailto: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 ?
>>>>
>>>
>>> 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)
Trevör
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
