Deprecate ActorIsolated.

[mbrandonw]

No description provided.

[ddanilyuk]

@mbrandonw
What is the reason for the deprecation of ActorIsolated?

[mbrandonw]

Hi @ddanilyuk, there just doesn't seem to be any pro to using ActorIsolated over LockIsolated. They both have the same guarantees, but one can be used in more situations than the other. So it seems best to not have to even give people a choice.

Do you have a situation where ActorIsolated is obviously better to use over LockIsolated?

It's also worth noting that soon Swift will have a native Mutex type that will even make our LockIsolated type unnecessary.

[ddanilyuk]

@mbrandonw Actually, I do not use ActorIsolated in my projects.

However, there is a situation where ActorIsolated works differently (and I think better) than LockIsolated. Assume you are on the main thread and using LockIsolated.withValue. This action will block the main thread while waiting for access to the synchronized property. Meanwhile, ActorIsolated won't block the thread in a similar action.

Isn't it better to use ActorIsolated when an async context is available, or am I missing something?

https://github.com/swiftlang/swift-evolution/blob/main/proposals/0433-mutex.md#differences-between-mutexes-and-actors

[honus]

@ddanilyuk point seems valid and important. Am I missing something?

[jshier]

Depends what you mean by better. IMO, ActorIsolated is only "better" if the resource is highly contended, and one of the waiters is the main queue. Otherwise, especially in the uncontended case, a lock is simpler and faster in pretty much all cases. And if your main queue is highly contended, you should probably be moving work off of it rather than looking for a different lock mechanism.

[honus]

ActorIsolated.withValue does move the work done off of the main queue. LockIsolated.withValue does not.

If you only have LockIsolated and your main queue is highly contended you're going to have to wrap your accesses of it in async methods to move your work off of main. This appears to me to be a situation where ActorIsolated is better than LockIsolated.