[swift-evolution] Question about async await

[Jean-Daniel]

> Le 20 sept. 2017 à 08:36, Trevör Anne Denise via swift-evolution <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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170920/53982413/attachment.html>