Hi all, is it feasible to implement erlang like supervision trees and process registries with actor
s?
Swift's actor
s kinda feel like erlang's gen_server
s
Hi all, is it feasible to implement erlang like supervision trees and process registries with actor
s?
Swift's actor
s kinda feel like erlang's gen_server
s
Yes and no, so since Swift actor's lifetimes are managed by ARC, and not completely memory isolated, we can't "let it crash" the same way as one can on the beam vm.
On the other hand, if you do cross a process boundary one can express the link / monitor style semantics, and we have done so in the cluster runtime implementation: https://swiftpackageindex.com/apple/swift-distributed-actors/main/documentation/distributedcluster/lifecycle:
distributed actor Juliet: LifecycleWatch {
deinit {
print("\(Self.self) terminated!")
}
distributed func watch(_ romeo: Romeo) {
watchTermination(of: romeo)
}
func terminated(actor id: ActorID) async {
print("Oh no! \(id) is dead!")
// *Stabs through heart*
}
}
So across nodes, if Romeo was on another node which crashes - we do indeed get notified about it. The distributed cluster's lifecycle monitoring pattern also works with local actors but only as much as "the watched actor was deinitialized" since within the same process we cannot crash individual actors.
This is separate from the language feature though -- it's a library solution on top of the language.
A registry is basically what we have in the cluster known as the receptionist. It is also well-typed so you discover distributed actors of known types.
So all these things are implementable on top of the existing language features, yes.
wow, that's awesome. I'll go play around with distributed actors :)
If you encounter any issues with the cluster lib let's chat over here: Distributed Actors - Swift Forums
It's not gotten as much maintanance recently as I would have wished but it should still be functional. Thanks for your interest!