Question about async await

Good article. Thanks.

···

Em sex, 22 de set de 2017 às 14:24, Kenny Leung via swift-evolution < swift-evolution@swift.org> escreveu:

Here’s more stuff I found on how this could work. It’s slowly becoming
less murky to me.

http://blog.stephencleary.com/2013/11/there-is-no-thread.html

-Kenny

On Sep 20, 2017, at 7:19 AM, Adam Kemp via swift-evolution < > swift-evolution@swift.org> wrote:

async/await doesn’t automatically make things run on another queue/thread.
The code you wrote would execute synchronously on the original thread.

--
Adam Kemp

On Sep 19, 2017, at 11:36 PM, Trevör Anne Denise via swift-evolution < > swift-evolution@swift.org> wrote:

Le 18 sept. 2017 à 18:07, Pierre Habouzit <pierre@habouzit.net> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise < > trevor.annedenise@icloud.com> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net> a écrit :

On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution < > 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 ?

Trevör

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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 ?
}

Thank you !

Trevör

···

Le 20 sept. 2017 à 21:15, Jean-Daniel <mailing@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 <pierre@habouzit.net <mailto:pierre@habouzit.net>> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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.

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.
}

···

Le 23 sept. 2017 à 12:23, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org> a écrit :

Le 20 sept. 2017 à 21:15, Jean-Daniel <mailing@xenonium.com <mailto:mailing@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 <pierre@habouzit.net <mailto:pierre@habouzit.net>> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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 ?
}

Do you mean that the API to execute the continuation back on its original thread ? (avoiding shared mutable state)

Trevör

···

Le 24 sept. 2017 à 12:00, Jean-Daniel <mailing@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 <mailing@xenonium.com <mailto:mailing@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 <pierre@habouzit.net <mailto:pierre@habouzit.net>> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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.
}

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

···

On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org> wrote:

Le 24 sept. 2017 à 12:00, Jean-Daniel <mailing@xenonium.com <mailto:mailing@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 <mailing@xenonium.com <mailto:mailing@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 <pierre@habouzit.net <mailto:pierre@habouzit.net>> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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)

I hope this will be handled automatically the compiler tough !

···

Le 25 sept. 2017 à 11:55, Thomas <tclementdev@free.fr> a écrit :

On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org> wrote:

Le 24 sept. 2017 à 12:00, Jean-Daniel <mailing@xenonium.com> a écrit :

Le 23 sept. 2017 à 12:23, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org> a écrit :

Le 20 sept. 2017 à 21:15, Jean-Daniel <mailing@xenonium.com> a écrit :

Le 20 sept. 2017 à 08:36, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org> a écrit :

Le 18 sept. 2017 à 18:07, Pierre Habouzit <pierre@habouzit.net> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net> a écrit :

On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution <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)

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

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 ?

···

Le 25 sept. 2017 à 13:33, Trevör ANNE DENISE <trevor.annedenise@icloud.com> a écrit :

Le 25 sept. 2017 à 11:55, Thomas <tclementdev@free.fr <mailto:tclementdev@free.fr>> a écrit :

On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 24 sept. 2017 à 12:00, Jean-Daniel <mailing@xenonium.com <mailto:mailing@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 <mailing@xenonium.com <mailto:mailing@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 <pierre@habouzit.net <mailto:pierre@habouzit.net>> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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)

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 ?

This thread had some ideas:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039349.html

C# uses the SynchronizationContext class <https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx <https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx>>. This class abstracts the concept of performing work synchronously or asynchronously using different threading models. For instance, there’s an implementation that posts messages to the UI thread and another that posts them to a thread pool. Each thread has a current context, which can be set with a static method.

The C# async/await feature itself doesn’t know anything about this, but its futures implementation (System.Threading.Tasks.Task) can be configured to run its continuation on the SynchronizationContext that was current when the task was started. If you use Task with async/await then it will “Just Work”. If you use some other futures implementation with async/await then it’s up to that implementation to decide what to do with the continuations.

I could imagine a concept like SynchronizationContext in Swift which captures the current queue and then can post work back to that same queue.

···

On Sep 25, 2017, at 9:54 AM, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org> wrote:

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 ?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

No. Async methods are not require to be dispatched on a queue and all threads are not required to have a queue.

···

Le 25 sept. 2017 à 18:54, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org> a écrit :

Le 25 sept. 2017 à 13:33, Trevör ANNE DENISE <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> a écrit :

Le 25 sept. 2017 à 11:55, Thomas <tclementdev@free.fr <mailto:tclementdev@free.fr>> a écrit :

On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 24 sept. 2017 à 12:00, Jean-Daniel <mailing@xenonium.com <mailto:mailing@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 <mailing@xenonium.com <mailto:mailing@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 <pierre@habouzit.net <mailto:pierre@habouzit.net>> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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)

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 ?

Thank you ! That's exactly what I was looking for !

Trevör

···

Le 25 sept. 2017 à 19:32, Adam Kemp <adam_kemp@apple.com> a écrit :

On Sep 25, 2017, at 9:54 AM, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Did anyone started to sketch a design for how giving back control to the calling queue will work ?

This thread had some ideas:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039349.html

C# uses the SynchronizationContext class <https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx <https://msdn.microsoft.com/en-us/library/system.threading.synchronizationcontext(v=vs.110).aspx>>. This class abstracts the concept of performing work synchronously or asynchronously using different threading models. For instance, there’s an implementation that posts messages to the UI thread and another that posts them to a thread pool. Each thread has a current context, which can be set with a static method.

The C# async/await feature itself doesn’t know anything about this, but its futures implementation (System.Threading.Tasks.Task) can be configured to run its continuation on the SynchronizationContext that was current when the task was started. If you use Task with async/await then it will “Just Work”. If you use some other futures implementation with async/await then it’s up to that implementation to decide what to do with the continuations.

I could imagine a concept like SynchronizationContext in Swift which captures the current queue and then can post work back to that same queue.

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 ?

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

···

On Sep 25, 2017, at 3:14 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:

Le 25 sept. 2017 à 18:54, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Le 25 sept. 2017 à 13:33, Trevör ANNE DENISE <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> a écrit :

Le 25 sept. 2017 à 11:55, Thomas <tclementdev@free.fr <mailto:tclementdev@free.fr>> a écrit :

On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 24 sept. 2017 à 12:00, Jean-Daniel <mailing@xenonium.com <mailto:mailing@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 <mailing@xenonium.com <mailto:mailing@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 <pierre@habouzit.net <mailto:pierre@habouzit.net>> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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)

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

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 ?

···

Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution@swift.org> a écrit :

On Sep 25, 2017, at 3:14 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 25 sept. 2017 à 18:54, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Le 25 sept. 2017 à 13:33, Trevör ANNE DENISE <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> a écrit :

Le 25 sept. 2017 à 11:55, Thomas <tclementdev@free.fr <mailto:tclementdev@free.fr>> a écrit :

On 25 Sep 2017, at 10:23, Trevör Anne Denise via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 24 sept. 2017 à 12:00, Jean-Daniel <mailing@xenonium.com <mailto:mailing@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 <mailing@xenonium.com <mailto:mailing@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 <pierre@habouzit.net <mailto:pierre@habouzit.net>> a écrit :

-Pierre

On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise <trevor.annedenise@icloud.com <mailto:trevor.annedenise@icloud.com>> wrote:

Le 18 sept. 2017 à 07:57, Pierre Habouzit <pierre@habouzit.net <mailto:pierre@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)

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 earlier response to this thread both linked to a previous thread about this and explained how C# does it. It will require some library support, but it can be done, and IMO should be done. As I’ve stressed repeatedly, async/await without this behavior will be very difficult to use correctly. I really hope we don’t settle for that.

···

On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:

Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

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 ?

Based on that thread and others it appears that Chris and Joe are both
alert to the danger that comes with queue-hopping inside a single scope, so
hopefully we won't end up in that world.

···

On Mon, Sep 25, 2017 at 3:13 PM, Adam Kemp via swift-evolution < swift-evolution@swift.org> wrote:

On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution < > swift-evolution@swift.org> wrote:

Le 25 sept. 2017 à 21:42, John McCall via swift-evolution < > swift-evolution@swift.org> a écrit :

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 ?

My earlier response to this thread both linked to a previous thread about
this and explained how C# does it. It will require some library support,
but it can be done, and IMO should be done. As I’ve stressed repeatedly,
async/await without this behavior will be very difficult to use correctly.
I really hope we don’t settle for that.

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Functional Programmer, iOS Developer, Surfs Poorly
http://twitter.com/n8gray

In C#, the model is far simple as there is not concept of a single dispatch queue that can execute work on any thread. You can easily use TLS to store a default context. Each UI thread can have a context that dispatch completion on the message queue, but AFAIK, there is not DispatchQueue Local Storage yet. Even something as simple as getting the current queue is not reliable (see dispatch_get_current_queue man page for details).

That’s why I’m saying it will be difficult to define a reasonable default context that can be used implicitly.

···

Le 26 sept. 2017 à 00:13, Adam Kemp <adam_kemp@apple.com> a écrit :

On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:

Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution@swift.org> a écrit :

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 ?

My earlier response to this thread both linked to a previous thread about this and explained how C# does it. It will require some library support, but it can be done, and IMO should be done. As I’ve stressed repeatedly, async/await without this behavior will be very difficult to use correctly. I really hope we don’t settle for that.

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 ?

My earlier response to this thread both linked to a previous thread about this and explained how C# does it. It will require some library support, but it can be done, and IMO should be done. As I’ve stressed repeatedly, async/await without this behavior will be very difficult to use correctly. I really hope we don’t settle for that.

In C#, the model is far simple as there is not concept of a single dispatch queue that can execute work on any thread. You can easily use TLS to store a default context. Each UI thread can have a context that dispatch completion on the message queue, but AFAIK,

there is not DispatchQueue Local Storage yet.

There is, see dispatch_queue*_specific()

Even something as simple as getting the current queue is not reliable (see dispatch_get_current_queue man page for details).

This is a sharp construct for clients, but not for the runtime / compiler that can be taught how not to fall in the traps of this API.

Just to debunk myths, dispatch_get_current_queue() is VERY WELL defined, but has two major issues: nesting & refcounting.

Nesting

Nesting refers to the fact that when you call code that takes a queue and a callback, you may observe *another* queue:

run_something_and_call_me_back(arg1, arg2, on_queue, ^{
    assert(dispatch_get_current_queue() == on_queue); // may crash
    ... my stuff ...
});

The reason is that run_something_and_call_me_back() may create a queue that targets `on_queue` and then this private queue is what is returned which is both unexpected and exposing internals of the implementation of run_something_and_call_me_back() which is all wrong.

A corollary is that people attempting to implement recursive locking (which is a bad idea in general anyway) with dispatch_get_current_queue() will fail miserably.

Refcounting

Because dispatch has a notion of internal refcount, in ARC world, this will crash most of the time:

dispatch_async(dispatch_queue_create_with_target("foo", NULL, NULL), ^{
    __strong dispatch_queue cq = dispatch_get_current_queue(); // will usually crash with a resurrection error
});

These two edges is why we deprecated this interface for humans.

1) A compiler though is not affected by the first issue because the context it would capture would have to not be programatically accessible to clients
2) The Swift runtime can know to take "internal" refcounts when capturing this hidden pointer and is not affected by the second problem either.

tl;dr: what is badly defined is allowing clients to get a pointer to the current queue with a real +1, but that is WAY stronger than what the language runtime needs.

That’s why I’m saying it will be difficult to define a reasonable default context that can be used implicitly.

This is just not true. This is both easy and reasonable.

-Pierre

···

On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:

Le 26 sept. 2017 à 00:13, Adam Kemp <adam_kemp@apple.com> a écrit :

On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:

Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution@swift.org> a écrit :

Pierre responded to the rest of your comments, but I wanted to briefly touch on this:

···

On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:

In C#, the model is far simple as there is not concept of a single dispatch queue that can execute work on any thread.

I don’t think this is true in general. The purpose of the SynchronizationContext abstraction is that it allows for different kinds of threading models, and I think the GCD model could work as well. It may be true that in a typical C# application using, say, WPF you don’t have that situation. In most C# frameworks you basically have the UI thread’s context and then you have the generic “thread pool” context. But the way that SynchronizationContext works should allow for you to create a GCD-like system. The way it would work is that when you enter a queue then you would push a SynchronizationContext for that queue, and when you exit the queue you would pop it (restore the previous context). The SynchronizationContext for the queue would implement the Post and Send methods to dispatch_async and dispatch_sync, respectively.

Again, it may be true that a typical C# application doesn’t need this, but I don’t think there’s anything blocking a GCD-like implementation on C# using their system. It’s pretty flexible. I believe a similar system could work for Swift.

I’m glade to be wrong about that point :wink:
One issue I still see is what should be the default when running on a bare pthread outside of any queue context. Or is there a queue associated with any thread ?

···

Le 26 sept. 2017 à 22:38, Pierre Habouzit <phabouzit@apple.com> a écrit :

On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 26 sept. 2017 à 00:13, Adam Kemp <adam_kemp@apple.com <mailto:adam_kemp@apple.com>> a écrit :

On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

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 ?

My earlier response to this thread both linked to a previous thread about this and explained how C# does it. It will require some library support, but it can be done, and IMO should be done. As I’ve stressed repeatedly, async/await without this behavior will be very difficult to use correctly. I really hope we don’t settle for that.

In C#, the model is far simple as there is not concept of a single dispatch queue that can execute work on any thread. You can easily use TLS to store a default context. Each UI thread can have a context that dispatch completion on the message queue, but AFAIK,

there is not DispatchQueue Local Storage yet.

There is, see dispatch_queue*_specific()

Even something as simple as getting the current queue is not reliable (see dispatch_get_current_queue man page for details).

This is a sharp construct for clients, but not for the runtime / compiler that can be taught how not to fall in the traps of this API.

Just to debunk myths, dispatch_get_current_queue() is VERY WELL defined, but has two major issues: nesting & refcounting.

Nesting

Nesting refers to the fact that when you call code that takes a queue and a callback, you may observe *another* queue:

run_something_and_call_me_back(arg1, arg2, on_queue, ^{
    assert(dispatch_get_current_queue() == on_queue); // may crash
    ... my stuff ...
});

The reason is that run_something_and_call_me_back() may create a queue that targets `on_queue` and then this private queue is what is returned which is both unexpected and exposing internals of the implementation of run_something_and_call_me_back() which is all wrong.

A corollary is that people attempting to implement recursive locking (which is a bad idea in general anyway) with dispatch_get_current_queue() will fail miserably.

Refcounting

Because dispatch has a notion of internal refcount, in ARC world, this will crash most of the time:

dispatch_async(dispatch_queue_create_with_target("foo", NULL, NULL), ^{
    __strong dispatch_queue cq = dispatch_get_current_queue(); // will usually crash with a resurrection error
});

These two edges is why we deprecated this interface for humans.

1) A compiler though is not affected by the first issue because the context it would capture would have to not be programatically accessible to clients
2) The Swift runtime can know to take "internal" refcounts when capturing this hidden pointer and is not affected by the second problem either.

tl;dr: what is badly defined is allowing clients to get a pointer to the current queue with a real +1, but that is WAY stronger than what the language runtime needs.

That’s why I’m saying it will be difficult to define a reasonable default context that can be used implicitly.

This is just not true. This is both easy and reasonable.

-Pierre

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 ?

My earlier response to this thread both linked to a previous thread about this and explained how C# does it. It will require some library support, but it can be done, and IMO should be done. As I’ve stressed repeatedly, async/await without this behavior will be very difficult to use correctly. I really hope we don’t settle for that.

In C#, the model is far simple as there is not concept of a single dispatch queue that can execute work on any thread. You can easily use TLS to store a default context. Each UI thread can have a context that dispatch completion on the message queue, but AFAIK,

there is not DispatchQueue Local Storage yet.

There is, see dispatch_queue*_specific()

Even something as simple as getting the current queue is not reliable (see dispatch_get_current_queue man page for details).

This is a sharp construct for clients, but not for the runtime / compiler that can be taught how not to fall in the traps of this API.

Just to debunk myths, dispatch_get_current_queue() is VERY WELL defined, but has two major issues: nesting & refcounting.

Nesting

Nesting refers to the fact that when you call code that takes a queue and a callback, you may observe *another* queue:

run_something_and_call_me_back(arg1, arg2, on_queue, ^{
    assert(dispatch_get_current_queue() == on_queue); // may crash
    ... my stuff ...
});

The reason is that run_something_and_call_me_back() may create a queue that targets `on_queue` and then this private queue is what is returned which is both unexpected and exposing internals of the implementation of run_something_and_call_me_back() which is all wrong.

A corollary is that people attempting to implement recursive locking (which is a bad idea in general anyway) with dispatch_get_current_queue() will fail miserably.

Refcounting

Because dispatch has a notion of internal refcount, in ARC world, this will crash most of the time:

dispatch_async(dispatch_queue_create_with_target("foo", NULL, NULL), ^{
    __strong dispatch_queue cq = dispatch_get_current_queue(); // will usually crash with a resurrection error
});

These two edges is why we deprecated this interface for humans.

1) A compiler though is not affected by the first issue because the context it would capture would have to not be programatically accessible to clients
2) The Swift runtime can know to take "internal" refcounts when capturing this hidden pointer and is not affected by the second problem either.

tl;dr: what is badly defined is allowing clients to get a pointer to the current queue with a real +1, but that is WAY stronger than what the language runtime needs.

That’s why I’m saying it will be difficult to define a reasonable default context that can be used implicitly.

This is just not true. This is both easy and reasonable.

I’m glade to be wrong about that point :wink:
One issue I still see is what should be the default when running on a bare pthread outside of any queue context. Or is there a queue associated with any thread ?

My thinking is that we need to have a notion of "current place to run swift bullshi^Wclosures".
It could be the current queue if there's one, or the current CFRunLoop (if there's one already made)
It could be the current "libfoobar event loop", ...

and if there's neither, then I think it would be completely appropriate to crash at runtime because it means you made a thread without the Swift runtime knowledge without any setup to allow running swift actors/asyncs/... on it and then called into Swift code that needs it.

In less joking tones, what I was thinking about is that the runtime should be able to have a way to get to the "current actor/async/.... context" for a thread which is an object that implements a given protocol that has the necessary methods to receive asyncs/actors/...

I hope I'm making sense.

-Pierre

···

On Sep 26, 2017, at 1:57 PM, Jean-Daniel <mailing@xenonium.com> wrote:

Le 26 sept. 2017 à 22:38, Pierre Habouzit <phabouzit@apple.com <mailto:phabouzit@apple.com>> a écrit :

On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 26 sept. 2017 à 00:13, Adam Kemp <adam_kemp@apple.com <mailto:adam_kemp@apple.com>> a écrit :

On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Awesome. That sounds like what I’ve been describing. :slight_smile:

···

On Sep 26, 2017, at 10:17 PM, Pierre Habouzit <phabouzit@apple.com> wrote:

In less joking tones, what I was thinking about is that the runtime should be able to have a way to get to the "current actor/async/.... context" for a thread which is an object that implements a given protocol that has the necessary methods to receive asyncs/actors/…

Terms of Service

Privacy Policy

Cookie Policy