Isolation Assumptions

[AronL (Aron Lindberg)]

@mattie

I think my original intention wasn't clear enough. Honestly, I'm confused even by then idea of actor NonSendableType. By making it an actor, wouldn't it become Sendable? And, if it does, then this type could be passed around freely to other isolation domains?

Yes, actors are always sendable and could be passed to other isolation domains.

@mattie

This is exactly the opposite of what I want to express! I want to tell the compiler that this type must never cross domains (non-Sendable achieves this) but that it also can know it is being isolated to something.

This to me is a contradiction, I am not sure I understand exactly what you are trying to achieve.

Assuming region-based-isolation is accepted into the language it would become legal to parse non-sendable objects across isolation domains in a subset of cases where the compiler can prove it is safe. So I am not sure a NonSendableType is a the best way to express a guarantee that a class does not crosses isolation domains.

What I don't get is this. If we had some way to mark a class as MustNeverCrossIsolationDomains, why do you care about it being isolated to something. If the class can't cross an isolation boundary it will always be accessed from the context where it was created. I assume you are trying to avoid data races or avoiding mutual access to mutable state, but neither of these can happen if the class can't cross isolation domains in the first place.

If we had a MustNeverCrossIsolationDomains feature I think it would come with some severe limitations:

1. A global variable can't be marked as MustNeverCrossIsolationDomains. A global variable can be accessed from any isolation domain.
2. If an object / class have an instance variable of type MustNeverCrossIsolationDomains, that outer object must also be marked as MustNeverCrossIsolationDomains, because if the outer object can be accessed from multiple isolation domains so can the inner object even if it is private to the class.

With those limits the use cases I can see is this:

A MustNeverCrossIsolationDomains object can be created as a temporary variable inside a single context / function call, assuming that object is deallocated at the end of that context.

An MustNeverCrossIsolationDomains object can be a private instance variable inside an actor. As an actor is a single isolation domain, so this is fine. As the private object is not sendable the actor can not send the object to other actors or isolation domains.

Again I fail to see exactly what you are trying to achieve here. If the question is "I want to have the protection of being in an isolation domain, but I want to provide synchronous functions to access the domain." The answer is, that would be possible, but such a feature would be vulnerable to potential deadlocks in the code.