+dispatcher offer GCD dispatcher; Enables Actors on DispatchQueues

[ktoso]

I realized we didn't offer a Dispatch based dispatcher, this implements it naively.

TODO: a few more tests

[yim-lee]

👍 Can take care of renaming (if wanted) in another PR

[yim-lee]

What does it do though? *Executor (comment right below) might be more fitting?

[ktoso]

Yeah good point... The word "scheduler" is sadly very overloaded -- could be "at some point in time scheduler" or those "just thread pool manager" – in libs like Rx or Combine those are called schedulers and technically it's the right word...

Akka wording was always "dispatcher" though I guess it's not necessarily the best... There the other words on the JVM are executors indeed. WDYT @drexin ? I'm somehow not in love with "dispatcher" the more i looked at it; "It schedules the actors execution" is kind of the right phrase, but "it executes the actor" also sounds correct I guess (though a bit macabre 😆 though actor internals often sound like that 😉).

• erlang wording is also scheduler https://hamidreza-s.github.io/erlang/scheduling/real-time/preemptive/migration/2016/02/09/erlang-scheduler-details.html
• akka wording: dispatcher https://doc.akka.io/docs/akka/current/dispatchers.html
  • conflates a bit with GCD / Dispatch, thus why I'm thinking about it again...
• Combine and Rx style libs call those Schedulers; https://developer.apple.com/documentation/combine/scheduler
• maybe indeed Executor?

[ktoso]

Note... we also have Scheduler:

internal protocol Scheduler {
    func scheduleOnce(delay: TimeAmount, _ f: @escaping () -> Void) -> Cancelable

    func scheduleOnce<Message>(delay: TimeAmount, receiver: ActorRef<Message>, message: Message) -> Cancelable

    func schedule(initialDelay: TimeAmount, interval: TimeAmount, _ f: @escaping () -> Void) -> Cancelable

    func schedule<Message>(initialDelay: TimeAmount, interval: TimeAmount, receiver: ActorRef<Message>, message: Message) -> Cancelable
}

which is the time related one, unlike MessageDispatcher today which is the "run the actor" one:

public protocol MessageDispatcher {
    // TODO: we should make it dedicated to dispatch() rather than raw executing perhaps? This way it can take care of fairness things

    var name: String { get }

    /// - Returns: `true` iff the mailbox status indicated that the mailbox should be run (still contains pending messages)
    // func registerForExecution(_ mailbox: Mailbox, status: MailboxStatus, hasMessageHint: Bool, hasSystemMessageHint: Bool) -> Bool

    func execute(_ f: @escaping () -> Void)
}

[ktoso]

The TODO there deciphered: // TODO: we should make it dedicated to dispatch() rather than raw executing perhaps? This way it can take care of fairness things

What I mean is scheduler.execute(actorShell) rather than scheduler.execute(mailbox.run), since then it knows which actor it's running and we can then in the future to some "locality" and "prefer the same thread as last time" etc tricks...

[ktoso]

Made the test do a bit more, will merge; thx for review!

[ktoso]

Ah, of course... the lovely platform differences 😉

            #if os(Linux)
            try p.expectMessage().shouldStartWith(prefix: "dispatchQueue:<Dispatch.DispatchQueue")
            #else
            try p.expectMessage().shouldStartWith(prefix: "dispatchQueue:<OS_dispatch_queue_global:")
            #endif