Swift GlobalActors & Dependencies

[idelfonsog2]

I know the topic of working with Swift Actors was mentioned at some point during the TCA video series. I'm curious to know if there are any reasons not to mix Dependency with a GlobalActor type.

The GlobalActor type enhances the Singleton pattern we have. A dependency can have a mutable state. I did read the docs about ActorIsolated Type in this library.

After implementing the globalActor to one of my Dependency wrapper, it's making me think maybe another need the Dependency var

[tgrapperon]

Having a global actor would help dependencies isolated on the same actor to interdepend synchronously. As I can imagine this happening in user code bases, I'm not sure there is something the library can do to help in this area, or maybe I'm not understanding your suggestion correctly.

You can of course isolate parts of your dependencies to global actors, and this is "commonly" performed with MainActor. It is also possible to completely isolate dependencies, but you'll need to mark liveValue & co as nonisolated to conform to DependencyKey (if you're using Self as Value), and you'll need to do a little gymnastic to synchronously create values of your isolated dependency to conform to the protocol anyway.

If this is not a singleton, I wouldn't recommend to implement your dependency as an actor itself, global or not. If you're not cautious, this reference-type will leak through dependencies overrides, and you may find bugs caused by action at distance that are difficult to fix. Whereas you're making this singleton a global actor is up to you, but I'm not exactly seeing how the library could help here, beside providing helpers to handle this object synchronously (if this is even possible in the general picture). Values that you extract from @Dependency can already be isolated to a global actor.

Do you have an example where the global actor is causing friction, or where the situation could be improved?

[idelfonsog2]

Thanks for the follow up. The thing that eludes me is the global actor! I feel that this would work the same with a simple actor having a shared static variable (the singleton). As I'm understanding it, the real interest would be if your dependency's clients are themself marked as @AnalyticsSingleton. This would allow them to work as if they were the actor themselves, that is to interact synchronously with actor-isolated properties and functions.
Maybe you're conflating being a global actor and being an actor with a shared instance.
Your problem can modelize very well using a shared actor instance. As an aside, you can probably refactor your dependency in the style described here and avoid having to create a protocol and type for the mock.
But going back to the main question: is there anything that you do with your dependency that you couldn't do by simply removing the @globalActor annotation? If it still builds after having removed this annotation, then you can probably go without a global actor. Please let me know if I missed your use case.

I do! My global actor holds a reference to X third-party SDK properties that I'm instantiating in the initializer of my globalActor. Any code in the application should interact with this unique instance because the configuration in the init needs to happen in the ... AppDelegate appDidFinishLunching method. Thats why Im mainy trying to enforce the use of @globalActor

import ThirdPartySDKAnalytics

@globalActor .... {
...
public init() {
  listener = AnalyticsListener(configPath:...)
}

func checkGuest() async {
  listener.remove()
  ...
}

[nashysolutions]

It might be good to put this in the documentation. Had memory leak issue today.

[mbrandonw]

Hi @nashysolutions, can you explain a bit more about what you want documented and the leak? I don't see anything in this thread that would cause leaks.

[nashysolutions]

Hi @mbrandonw sorry for late reply. @tgrapperon mentioned the following above

...If this is not a singleton, I wouldn't recommend to implement your dependency as an actor itself, global or not. If you're not cautious, this reference-type will leak through dependencies overrides...

[tgrapperon]

To be clear, the "leak" I was talking about wasn't a memory leak, but rather a way to say that the same instance may be shared by different override contexts simultaneously. There are thus cases where the parent may act using some child's overrides rather than its own values.

For example, if your dependency is a class with configurable/unimplemented endpoints, if you override one in a child, this will also override the parent's one too, and this will furthermore not be reset when the child context ends.

Sorry if the term led to confusion. I should probably have used "bleed" instead.