As of XCode 15.3 (15E204a) we are getting a slew of new warnings about OpaquePointers in the Noosphere wrappers.
Problem
The problem stems from our Noosphere wrappers being individual actors, and OpaquePointers not being a sendable type (e.g. they should not cross state synchronization boundaries). That makes sense.
Design considerations
We implement Noosphere, Sphere, and SphereFile as actors because:
We want to get Noosphere work off the main thread. Actors nudge code off the main thread
Although this is not a hard guarantee of the green thread runtime IIRC, but it should do whatever it needs to do keep the main thread clear for UI.
We want the state isolation and synchronization guarantees provided by an actor.
Since they're currently separate actors, we're passing OpaquePointers across actor boundaries. Anything passed across actor boundaries should be sendable (e.g. no shared mutable state. However, it's not really necessary that these be separate actors, just that they have actor isolation. Preferably, we should have them isolated to the same actor.
Solution: global actor
Swift introduced @globalActor to solve for this kind of "many things isolated to the same actor context" problem.
By wrapping a new NoosphereActor shared actor in @globalActor and conforming to the protocol, we get a @NoosphereActor decorator we can use to isolate classes and functions.
Noosphere, Sphere, and SphereFile all become final classes, isolated. to @globalActor.
As of XCode 15.3 (15E204a) we are getting a slew of new warnings about OpaquePointers in the Noosphere wrappers.
Problem
The problem stems from our Noosphere wrappers being individual actors, and OpaquePointers not being a sendable type (e.g. they should not cross state synchronization boundaries). That makes sense.
Design considerations
We implement Noosphere, Sphere, and SphereFile as actors because:
Since they're currently separate actors, we're passing OpaquePointers across actor boundaries. Anything passed across actor boundaries should be sendable (e.g. no shared mutable state. However, it's not really necessary that these be separate actors, just that they have actor isolation. Preferably, we should have them isolated to the same actor.
Solution: global actor
Swift introduced
@globalActorto solve for this kind of "many things isolated to the same actor context" problem.By wrapping a new
NoosphereActorshared actor in@globalActorand conforming to the protocol, we get a@NoosphereActordecorator we can use to isolate classes and functions.Noosphere,Sphere, andSphereFileall become final classes, isolated. to@globalActor.Resources