[Returned for revision] SE-0392: Custom Actor Executors

Hi everyone. Thanks to everyone who participated in the review for SE-0392, Custom Actor Executors. The Language Workgroup accepts the proposal in principle, but has decided to return the proposal for revision. There are some relatively minor changes to the proposed API that we would like to see explored in a second round of review:

  • The proposal offers a function assertOnActorExecutor(_: Actor) to assert that code is currently executing on the executor for a given actor instance, and some reviewers found the name confusing as to whether the actor instance itself or its sharedUnownedExecutor reference ought to be passed. The Language Workgroup wants to suggest turning this standalone function into a method, if possible. Variants of the method could be provided including an instance method for instantiated actors, a static method for global actors, and an instance method for serial executors, allowing for code to read naturally in any of the three cases.

  • There was concern about the use of the common term Job as a standard library type, both because it's likely to be frequently shadowed by Job declarations in other modules, and because Job has similar connotations to Task, and the presence of Job and Task types together would be likely to confuse some developers. The Language Workgroup expects that code working with custom executors and jobs will be far less common than code that works with tasks, so giving the type a more unique and descriptive name like ExecutorJob would be appropriate. (If it were possible, the qualified name Executor.Job would be nice, but since Executor is a protocol, that would mean that every implementation of Executor would end up with a Job type nested inside it.)

  • The proposal defines Job as a noncopyable type, which the Language Workgroup agrees is a great use of the new language feature, and the right thing to do. However, we expect that developers are likely to run into limitations given the initial subset of noncopyable type support provided by SE-0390. The proposal states that APIs using the UnownedJob type, which does not statically enforce single ownership will be deprecated, but we expect that developers may need to use UnownedJob in the short- to medium-term to express things that are difficult to achieve with a noncopyable Job. We agree that use of Job should be encouraged where possible, but that it should be clear that UnownedJob remains available as an escape hatch while the capabilities of noncopyable types continue to develop.

  • There was good discussion of what should happen when code asks a distributed actor instance what its executor is. The question doesn't really make sense to ask of a remote actor instance, since the only code that locally executes on its behalf is the nonisolated remote call stub, and it doesn't make sense to try to enqueue additional local work on a remote actor's executor. One possibility would be to have the unownedExecutor property of an actor be Optional, and have distributed actor instances return nil, but the Language Workgroup agrees with the proposal's choice not to take this route, since doing so would add friction to code that only works with local actors. Instead of returning a "default" executor, though, the language workgroup would like to see if it's possible to use an executor implementation that raises a fatalError if any code tries to enqueue additional jobs on it. Although it may make sense to ask an arbitrary actor for its executor to log the value as a debugging aid, it is likely a programming mistake to attempt to use that executor reference to enqueue work, so it may be preferable to trap at the attempt rather than to fall back to some default executor, to avoid expectations that the work will actually occur exclusively with work being done on the remote actor instance.

Thank you again to everyone who helped participate in the review!

22 Likes

Thanks a lot everyone for the feedback and for the writeup @Joe_Groff, I'll prepare a follow up update to the proposal text then.

Update in-flight here: [SE-0392] update according to review feedback by ktoso ยท Pull Request #2000 ยท apple/swift-evolution ยท GitHub some of them already implemented.

6 Likes

Second review is in progress now over here: [Second review] SE-0392: Custom Actor Executors