Initial PoC of Custom Actor Executor support

[Lukasa]

This PR tracks an example of custom actor executor support, as well as updating our AsyncAwait example to clearly annotate (via precondition[Not]OnEventLoop) whether the code in question is executing on the event loop or not.

The initial conclusion here is that this demonstrates the strengths and limitations of custom actor executors for the NIO model. Actors running on an event loop executor clearly run on the event loop, such that the NIO fast-path successfully fires. However, free functions and non-actor types do not inherit this execution context, which limits the utility of our existing async sequences (which are not actors and cannot be EL bound).

[FranzBusch]

Great PoC!

However, free functions and non-actor types do not inherit this execution context, which limits the utility of our existing async sequences (which are not actors and cannot be EL bound).

Can we try out marking our NIOAsyncSequenceProducer methods with @_inheritActorContext and having an example how this works with NIOAsyncChannel? In theory if the actor that is consuming the NIOAsyncSequenceProducer is using the NIO executor we should get a fast path right?

[John-Connolly]

This is super interesting I'm eager to see what you come up with. It would be ideal if swift had a way to express that everything in this closure will get executed on a specific executor unless Task.detached is called or another task with a specified actor is started. I'm unsure how to model a Request -> Response scenario without that. The only solution i've come up with is to pass and isolated Actor as a parameter to every function I want to be run on a executor.

[FranzBusch]

I am wondering if we really should default to this or are better off with a fatalError. We are making sure our ELs implement this sensible but if somebody created their own EL and we use the default I am a bit concerned that users will just run into crashes for which we could provide a better fatalError message.

[Lukasa]

I'm inclined to want to leave it. The current behaviour will work in the vast majority of cases, and the crashes will be correctness issues anyway.

[FranzBusch]

Yeah probably it's okay since all our ELs do the right thing and there aren't many other ELs out there.

[ktoso]

Seems okey to leave this IMHO 👍

[Lukasa]

Applied your nit.

[ktoso]

Looks good 👍 Too bad we couldn't put it onto EL right away but this is okey

[FranzBusch]

Just circling back here. If we want there is a way to create a custom serial executor without warnings on 5.9 and blow like this

#if swift(<5.9)
final class MyExecutor: SerialExecutor {
    func enqueue(_ job: UnownedJob) {
        job._runSynchronously(on: self.asUnownedSerialExecutor())
    }

    func asUnownedSerialExecutor() -> UnownedSerialExecutor {
        UnownedSerialExecutor(ordinary: self)
    }
}
#else
@available(macOS 14.0, iOS 17.0, watchOS 10.0, tvOS 17.0, *)
final class MyExecutor: SerialExecutor {
    @available(macOS 14.0, iOS 17.0, watchOS 10.0, tvOS 17.0, *)
    func enqueue(_ job: __owned ExecutorJob) {
      job.runSynchronously(on: asUnownedSerialExecutor())
    }

    func asUnownedSerialExecutor() -> UnownedSerialExecutor {
        UnownedSerialExecutor(ordinary: self)
    }
}
#endif

[Lukasa]

Thanks Franz. It's a good suggestion but I'm inclined not to do it: using both _runSynchronously and __owned makes me really quite nervous about the stability of that code. @weissi are you happy with having this API on 5.9 only?

[weissi]

I'm happy with having APIs that are available everywhere from a certain Swift version. But it should be #if compiler not #if swift