> On Sep 25, 2017, at 3:14 PM, Jean-Daniel via swift-evolution
> <[email protected]> wrote:
>> Le 25 sept. 2017 à 18:54, Trevör Anne Denise via swift-evolution
>> <[email protected] <mailto:[email protected]>> a écrit :
>>
>>>
>>> Le 25 sept. 2017 à 13:33, Trevör ANNE DENISE <[email protected]
>>> <mailto:[email protected]>> a écrit :
>>>
>>>
>>> Le 25 sept. 2017 à 11:55, Thomas <[email protected]
>>> <mailto:[email protected]>> a écrit :
>>>
>>>>
>>>>> On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution
>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>>
>>>>>> Le 24 sept. 2017 à 12:00, Jean-Daniel <[email protected]
>>>>>> <mailto:[email protected]>> a écrit :
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Le 23 sept. 2017 à 12:23, Trevör Anne Denise via swift-evolution
>>>>>>> <[email protected] <mailto:[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.
>>>>>> }
>>>>>
>>>>>
>>>>> 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).
John.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
