I’ve been testing using the DistributedCluster library in a watchOS app using a server-client configuration not too far off from TicTacFish. In the simulator it works great, but when I compile the app for my Series 7 watch, I get an overflow error and crash from a method in the DistributedCluster library.
With some research I’ve found this is because Xcode builds arm64 binaries for the watchOS Simulator, but builds arm64_32 binaries for the Apple Watch. (I take arm64_32 to be arm64 math, but with 32 bit pointer addresses1) It’s a configuration I don’t know how to test, but an important one for testing since it has these bug opportunities you won’t see running unit tests compiled for arm64 only.
I’m fully prepared to investigate the crash I’m seeing and write a patch, but not being able to run tests for arm64_32 from within Xcode really hampers that process. Currently the only way I see to find these issues is to wait for the device to crash, and/or try to trap a breakpoint over a wireless connection. This is cumbersome, so I’m hoping for any community wisdom on this: How can we test for arm64_32 processors so swift-distributed-actors can shine on watchOS as well?
1 This is the description generally given on the internet for this processor's unique efficiency-oriented configuration, but it goes farther than just using 32-bit addressing. Values like Int are 32-bit as well.
It's probably not the answer you're after, however, if targeting at least watchOS 9 is fine for you, you could get rid of arm64_32 altogether for the device.
Having that said -- the watch is not really a platform supported by the cluster. The cluster is not designed with battery efficiency and mobile devices in mind and it must keep connections open and active by continuously sending heartbeat messages between nodes. Its primary deployment target is server-side distributed compute clusters.
It is very cool to see people reaching for distributed actors on device as well, this might not be the best system implementation for this deployment target
I would recommend writing a different style of distributed actor system that's using bonjour and network framerwork if you're interested in using distributed actors across devices.
Would you mid me asking what kind of use cases you're looking at?
I'd be happy to give hints and and tips for implementing a DistributedActorSystem implementation that's more suited for devices!
Those are great points and I'm glad you brought them to my attention. I'm still getting the hang of the distributed actors way of looking at things and would love to use them on the watch to handle bi-directional communications between the watch and a service running on a server.
The pattern I'd like to implement is to have an inbox actor that lives on the watch that the server can keep track of and push messages to while the app is in active use. To preserve the battery, I think it would be best to eagerly deinitialize the inbox as soon as possible and allow the actor system to spin down any connections to the server, probably just a few seconds after the user's last interaction with the app. In this state the actor system could wait for a push notification through APNS to re-establish the actor for further updates if necessary, or even skip the reconnection process all together if the payload is small enough to be carried by APNS.
I think it's amazing to be able to compile and run a cluster system designed for servers and computers with less constraints than the watch even if it is a battery hog in the mean time -- the ability to swap that system for one leaner and focused to the task at hand makes that doubly so. (I could keep going on that, lots of really cool stuff here.)
Do you think the WebSocketActorSystem from the TicTacFish would be a good place to start hacking this server-client battery-focused actor system together?
