SE-0304 (4th review): Structured Concurrency

[Douglas_Gregor]

@Chris_Lattner3

The Context Inheritance section (and the later Actor context propagation section) says this about launching unstructured tasks from within an actor context:

• if executed within the scope of a specific actor function:
  • inherit the actor's execution context and run the task on its executor, rather than the global concurrent one,
  • the closure passed to Task {} becomes actor-isolated to that actor, allowing access to the actor-isolated state, including mutable properties and non-sendable values.

What does "specific actor function" mean in this case? Does that mean from within a method lexical defined on the actor type, or does this mean a function dynamically executing on an actor's executor?

It's the lexical context.

@Chris_Lattner3

If it is the former, this poses some potentially very surprising behavior, because refactoring a method in an actor out to a global function (or method on some other type) will cause a behavior change. This seems surprising and we should carefully consider this. If the refactored code would work naturally (because it is still on the current actors executor) then there is no concern here.

Factoring out a closure already causes behavior changes, because closures are fairly sensitive to the context in which they are written:

• You no longer get @Sendable
• You can't get a non-escaping closure any other way
• You don't have type context to resolve the parameter / result types if they aren't spelled out

Moreover, changes in actor isolation are rarely silent. If you actually use anything from the actor, you'll go from in-actor synchronous access to requiring await and it'll be clear what needs to be done with isolated parameters.

@Chris_Lattner3

Related to the above question, Implicit "self" mentions this:

Closures passed to the Task initializer are not required to explicitly acknowledge capture of self with self. .... Note : The same applies to the closure passed to Task.detached and TaskGroup.addTask .

How is this implemented and why is special support required? Implicit vs explicit self has been widely discussed in the community and has pervasive impact on the language.

It's an underscored parameter attribute @_implicitSelfCapture. Its presence suppresses the requirement for explicit self capture.

Explicit self is there for a specific purpose: to help identify retain cycles by requiring one to explicitly call out self capture where it's likely to cause retain cycles. We intentionally did not make it required everywhere, and then later we removed explicit self in other unlikely scenarios. When capturing self in a task, you effectively need the task to have an infinite loop for that capture to be the cause of a reference cycle. That fits very well with the direction already set for explicit self.

It's an underscored attribute because we know we want this effect for the code running in a task, and that's why it's here in this proposal. It's not unlike the "marker protocol" for Sendable in that we know we want the effect, but we want more time to make it available for general use. We should have the discussion later about "dropping the underscore" from the attribute to make this a general feature that will help explicit self be meaningful, but we shouldn't make task creation worse while waiting for that discussion to happen.

@Chris_Lattner3

Thank you for adding the nanoseconds: label. I think this is well motivated and is a great step.

One further question: why is the duration a UInt64 ? Swift generally uses Int as the currency type for values like this, even those that are logically unsigned (e.g. the result of count ). Shouldn't this be an Int ?

This was already answered, but just to reiterate here: a 32-bit Int is too small when we're counting in nanoseconds.

@Chris_Lattner3

I have concerns with each of these, and a simple suggestion for how to resolve it:

1. On the first, I am concerned that the verb in group.addTask { .. } is "add". This would make sense if TaskGroup were primarily a collection-like entity, but I don't think that is its primary function. I see it as an orchestrator of concurrent tasks which launches and tracks them (in an internal collection), managing and structuring their execution. The verb "add" is an implementation detail of how it maintains its internal collection, not the primary action that the client needs to think about.

A task group is a collection, though, which is an important part of the API contract. The way you get the result from a task that's been added to the task group is to get the values out of the task group using collection-like syntax (e.g., by iterating through the group with for...in). Something like group.runTask { ... } or group.launchTask { ... } emphasizes the the execution of the task, but it's the membership in the group that's the important action here. Hence, the "add" verb emphasizes the more important point.

@Chris_Lattner3

On the second, I am concerned that the proposal uses an unlabeled initializer on a value type -- but its primary operation is to provide a global side effect of launching a new task . This leads to some surprisingly subtle code, e.g. see this post which suggests the best way to “fire and forget” some work off to the Main actor is:

Task { @MainActor in hello() }

While anything can be taught, this doesn't scream "I'm launching a new task that runs independently of the current one" because there is no verb.

What is the point of creating a Task if not to run it? This API is intentionally declarative---we are emphasizing that you are creating a task, and the task is associated with the provided function/closure.

It is conceivable that at some point we'll have the ability to create a task without running it, but that would be used much less often and would want to be called out very specifically, e.g., Task(.suspended) { ... }. That seems preferable to launchTask(.suspended) { ... } (it's not launched if it's suspended) or having to come up with another verb (createSuspendedTask { ... } or similar).

@Chris_Lattner3

On the third, the verb detach doesn't convey the right action happening here and is inconsistent with other static members on Task . The other static methods on Task apply to the current task . This operation doesn't detach the current task, it is launching a new task "that is detached" from the current one.

It's Task.detached { ... }, an adjective describing the result of the operation, just like RandomAccessCollection.sorted. Like the Task { ... } initializer, it describes what you're creating---and the primary reason to create a task is to run it, so we don't need to call that out repeatedly with "launch" everywhere.

@Chris_Lattner3

My suggestion is to make a very minor tweak to the proposal, standardize of the compound verb phrase "launchTask", and use global functions for each of these. This would give the following design:

1. Structured task groups: group.launchTask { ... }
2. Unstructured attached tasks: let handle = launchTask { ... }
3. Unstructured detached tasks: let handle = launchDetachedTask { ... }

To reiterate, I consider (1) to be a regression from group.addTask because it emphasizes the wrong thing, and (2)-(3) to be unnecessary verbosity as well as making "create a suspended task" more awkward should we add it in the future.

Doug