[Pitch #2] Structured Concurrency

John_McCall · 2020-12-31T00:37:59.476Z

withGroup does wait for the child tasks to all complete; if that isn’t clear in the document, we need to fix that.

John_McCall · 2020-12-31T00:40:21.807Z

If a parent task gives up on waiting for its child tasks, for whatever reason, they are cancelled (and waited for).

anandabits · 2020-12-31T00:44:26.203Z

John_McCall:

Whether a task throws is a mostly independent question from cancellation. They are related only in that certain functions may choose to react to cancellation by throwing. A task throwing does not mean it was cancelled, and it doesn't by itself cancel any sibling or parent tasks, so I'm not sure how to interpret your specific case.

This bit of the proposal is what I had in mind:

child tasks in the proposed structured-concurrency model are (intentionally) more restricted than general-purpose futures. Unlike in a typical futures implementation, a child task does not persist beyond the scope in which it was created. By the time the scope exits, the child task must either have completed, or it will be implicitly awaited. When the scope exits via a thrown error, the child task will be implicitly cancelled before it is awaited.

Bringing it back to our example, note that the chopVegetables() function might throw an error if, say, there is an incident with the kitchen knife. That thrown error completes the child task for chopping the vegetables. The error will then be propagated out of the makeDinner() function, as expected. On exiting the body of the makeDinner() function with this error, any child tasks that have not yet completed (marinating the meat or preheating the oven, maybe both) will be automatically cancelled

John_McCall · 2020-12-31T01:47:20.535Z

Okay. To answer what I think your question is, if a scope makes a couple child tasks, and one of them throws, and the parent task awaits that task, and it doesn’t handle the thrown error and just lets it unwind from the scope which created the child tasks, then all the still-running child tasks will be cancelled, and the error will continue propagating in the parent task as soon as all of those child tasks complete. But this is just compositional semantics: awaiting a throwing task handle receives the result of that task, including rethrowing any error it threw, and running child tasks are cancelled when the spawning scope exits.

ktoso · 2020-12-31T02:12:16.616Z

xwu:

ktoso:

The wording I thought of this being instantaneous is because "can not suspend", but totally open to other names.

I have thoughts about this proposal generally having to do with the user experience. As a start it would be helpful, I think, to name things exactly as we mean them.

If the meaning desired here is “cannot suspend,” I would hope that we would name the annotation @nonsuspending or something similar. Or we could write async(nonsuspending) .

Yeah, absolutely.

You'll be happy to know after posting this I spent a sleepless night debating if I should get up and post that this likely should bee called @suspends(never)... Kind of also taking into account the suspends feedback that @kavon had in other threads.

Dante-Broggi · 2020-12-31T02:20:00.898Z

Syntactically I think it would be better to have async replace await directly in an "async let" statement instead of being lifted to be in front of the let.
e.g:

{
let ok = async "ok",
    (yay, nay) = async ("yay", throw Nay())
  await ok
  try await yay
}

ktoso · 2020-12-31T02:25:59.044Z

anandabits:

If child tasks are able to execute concurrently then how are data races avoided?

The same way as escaping closures -- they cannot close over things which would be unsafe to access.

Doug had a good example of this recently, as he implemented the checks for local variables as well and spotted a bug in an example we had: https://twitter.com/dgregor79/status/1341941190896185352

I don't see it spelled out explicitly in the proposal, but if falls out of the semantics of what an async let initializer is:

The simplest way to think about it is that anything to the right hand side of the = of an async let is initiated together (as-if in an asynchronous closure), implying that if any of the values initialized by this closure throws, all other left-hand side to-be-initialized variables must also be considered as it they had thrown that error.

I.e. it's a concurrent closure, and thus all checks that are made for those apply to child tasks as well.

Could be good to add a specific example about this in to the proposal.

anandabits · 2020-12-31T02:28:14.004Z

Right, my question was: if a group has two children A and B both running on a non-exclusive executor and B has a cancellation handler installed, then if a partial task for both A and B are executing concurrently and A throws, what is the semantics for execution of B’s handler relative to its currently executing partial task? Based on your earlier post it sounds like the cancellation handler is executed concurrently with the task. Is that correct?

In general, can you elaborate in more detail about non-exclusive executors? The proposal is very sparse in details about those.

jackpal · 2020-12-31T03:19:08.663Z

How can structured concurrency work with an API like

Apple Developer Documentation ?

Ideally I want to be able to write a function

func asyncDataTask(with: url: URL) async -> (Data?, URLResponse?, Error?) {
 ...
 let dataTask = URLSession.shared.dataTask(with: url) ... ??? ...
}

// Used like this:
 async let result = asyncDataTask(with: url)

My goal is to have asyncDataTask work with async let and automatically handle Task cancelation.

When I try to write asyncDataTask, I am running into the following issues:

URLSession.dataTask() returns a URLSessionDataTask object, so it doesn't get the
automated conversion to async that is provided for simpler asynchronous APIs that return void.
There doesn't seem to be a way of registering a cancelation handler to call dataTask.cancel() when the implicit "let async" task is canceled.

Jon_Shier · 2020-12-31T03:53:20.517Z

It seems unlikely URLSession's current API will map directly to async functions, unless a new overlay is created, as URLSessionTasks are created synchronously and must be manually resumed. So I think you'd use the Task APIs directly to wrap those calls, returning the data types you want. But I haven't yet fully explored the proposal.

jackpal · 2020-12-31T04:32:29.747Z

Right, the question is if it's possible to wrap the URLSessionDataTask inside an ordinary async function, for the situation where we don't want to expose the fancy URLSessionDataTask features.

I see how I can use the Task api to wrap URLDataTask. But I don't see how to use the resulting Task object to produce a function with the signature

func asyncDataTask(with: url: URL) async -> (Data?, URLResponse?, Error?)

Yet it seems like something that should be possible.

Jon_Shier · 2020-12-31T05:29:41.438Z

Not unless you're okay losing access to the URLSessionTask. Otherwise you'd likely want to package everything in an actor (similar to what Alamofire does now, manually, with our Request types) which manages access to the URLSessionTask and response state.

But again, I haven't fully explored everything here.

jackpal · 2020-12-31T05:33:27.029Z

Yeah, I'm happy to lose access to the URLSessionTask as long as it's still cancelable through the Task API. I guess I need to noodle around with Task, TaskHandle.get and related APIs and see if there's some way to make things work.

linqingmo · 2020-12-31T05:34:40.476Z

extension URLSession {
    func asyncDataTask(with url: URL) async -> (Data?, URLResponse?, Error?) {
        await withUnsafeContinuation { continuation in
            dataTask(with: url) { data, response, error in
                continuation.resume(returning: (data, response, error))
            }
        }
    }
}

jackpal · 2020-12-31T05:37:34.773Z

Nice! That still needs the dataTask to be resumed(), and for the dataTask cancelation to be hooked up to the Task cancelation, but I bet it's on the right track.

extension URLSession {
  func asyncDataTask(with url: URL) async -> (Data?, URLResponse?, Error?) {
    var dataTask: URLSessionDataTask?
    return await try Task.withCancellationHandler(handler: {
      if let dataTask = dataTask {
        dataTask.cancel()
      }
    }) {
      await withUnsafeContinuation { continuation in
        dataTask = self.dataTask(with: url) { data, response, error in
          continuation.resume(returning: (data, response, error))
        }
        // Do I have to check for the Task already being canceled at this point?
        dataTask!.resume()
      }
    }
  }
}

Might work, but I get an "Abort trap: 6" error when I try to compile that on the Dec 23rd Swift toolchain release.... Rewriting as below looks cleaner, it doesn't have the race condition, but it also doesn't compile due to a type error:

extension URLSession {
  func asyncDataTask(with url: URL) async -> (Data?, URLResponse?, Error?) {
    withUnsafeThrowingContinuation { continuation in
      let dataTask = self.dataTask(with: url) { data, response, error in
        continuation.resume(returning: (data, response, error))
      }
      await try Task.withCancellationHandler(handler: {
        dataTask.cancel()
      }) {
        dataTask.resume()
      }
    }
  }
}

Due to "Invalid conversion from throwing function of type '(UnsafeThrowingContinuation<(Data?, URLResponse?, Error?)>) async throws -> Void' to non-throwing function type '(UnsafeThrowingContinuation<(Data?, URLResponse?, Error?)>) -> Void'"

John_McCall · 2020-12-31T06:30:39.244Z

What I’m trying to point out is that your question can be broken down. You’re setting up a complex scenario where a task (P) has two child tasks, one of which (X) throws and (presumably) ultimately causes the parent task to exit the scope in which the child tasks were created. That is an elaborate way of saying that the other child task (Y) is cancelled. From Y’s perspective, that cancellation is no different from any other kind of cancellation, which is to say that it is (potentially) concurrent with Y’s execution; specifically, any cancellation handlers Y has may run concurrently with the normal execution of Y. If Y only needs to do something non-concurrently on cancellation, it can of course just check at any time during its normal execution whether it has been cancelled, and it doesn’t need to mess around with cancellation handlers at all.

jackpal · 2020-12-31T06:57:28.067Z

Well, the use of URLSession.dataTask, with all its extra features, may be something of a red herring here. I just want to implement a simple "fetch this URL" async function that works correctly with structured concurrency.

The following compiles, but fails at runtime with "Fatal error: withCancellationHandler(handler:operation:) not implemented yet."

(Plus resulting task is detached, so doesn't automatically get canceled.)

I'll give up on cancellation for now.

extension URLSession {
  func asyncDataTask(with url: URL) async -> (Data?, URLResponse?, Error?) {
    await withUnsafeContinuation { continuation in
      let dataTask = self.dataTask(with: url) { data, response, error in
        continuation.resume(returning: (data, response, error))
      }
      _ = Task.runDetached {
        return await try! Task.withCancellationHandler(handler: {
          dataTask.cancel()
        }) {
          dataTask.resume()
        }
      }
    }
  }
}

Pardon me for adding onto this comment, but as a new member of the forum I'm not allowed to reply more than three times. I ported a toy web scraper app to Structured Concurrency. I wanted to report that I ran into 3 issues:

The above issues adapting URLSession.dataTask()
I wrote an asyncMap() method using Task.withGroup, and it required that transform closure be marked "@escaping" which doesn't seem right. Is there a way of avoiding "@escaping"?
When I tried to return results from async code to sync code, across a runAsyncAndBlock boundary I got a "Local var is unsafe to reference in code that may execute concurrently" warning. Is there a way of fixing that?

For reference, here's my asyncMap, based on the chopVeggies code from the Structured Concurrency doc:

extension Array {
  func asyncMap<B>(_ transform: @escaping (Element) async throws -> B) async throws -> [B] {
    await try Task.withGroup(resultType: (Int, B).self) { group in
      for i in self.indices {
        await group.add {
          (i, await try transform(self[i]))
        }
      }
      var result = [B?](repeating: nil, count: count)
      while let (index, transformed) = await try group.next() {
        result[index] = transformed
      }
      return result.map { $0! }
    }
  }
}

jayton · 2020-12-31T10:13:35.082Z

It seems… inharmonious… that non-throwing tasks are represented by Task.Handle where Failure == Never, but UnsafeContinuation and UnsafeThrowingContinuation are distinct types. Wouldn’t it make sense to have:

// Generic arguments renamed to match Task.Handle instead of single letters
struct UnsafeContinuation<Success, Failure: Error> {
  func resume(returning: Success)
  func resume(throwing: Failure)
}

func withUnsafeContinuation<Value>(
    operation: (UnsafeContinuation<Value, Never>) -> Void
) async -> Value

func withUnsafeThrowingContinuation<Success>(
    operation: (UnsafeContinuation<Success, Error>) -> Void
) async throws -> Success

xwu · 2020-12-31T11:40:21.830Z

ktoso:

Yeah, absolutely.

You'll be happy to know after posting this I spent a sleepless night debating if I should get up and post that this likely should bee called @suspends(never) ... Kind of also taking into account the suspends feedback that @kavon had in other threads.

Simpler yet for the surface model, this can be spelled async(nonawaiting) or @nonawaiting func ... async.

Note that for full functionality, this would have to be accompanied by the introduction of a withoutActuallyAwaiting (or withoutActuallySuspending) so that the implementation of these functions can call other async functions that haven't been annotated as non-suspending but are known never to suspend.

Lantua · 2020-12-31T12:39:20.413Z

jackpal:

Is there a way of avoiding "@escaping"?

You need to use withoutActuallyEscaping, which is quite apt since transform does escape group.add. It just doesn't escape Task.withGroup.