Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate ActorIsolated. #29

Merged
merged 1 commit into from
Jun 23, 2024
Merged

Deprecate ActorIsolated. #29

merged 1 commit into from
Jun 23, 2024

Conversation

mbrandonw
Copy link
Member

No description provided.

@mbrandonw mbrandonw requested a review from stephencelis June 21, 2024 14:28
@mbrandonw mbrandonw merged commit 675c56c into main Jun 23, 2024
7 checks passed
@mbrandonw mbrandonw deleted the deprecated-actorisolated branch June 23, 2024 14:07
@ddanilyuk
Copy link

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

@mbrandonw
Copy link
Member Author

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
Copy link

@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
Copy link

honus commented Aug 2, 2024

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

@jshier
Copy link

jshier commented Aug 2, 2024

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.

acevif added a commit to acevif/swift-concurrency-extras that referenced this pull request Aug 6, 2024
- Fixed typo introduced in PR pointfreeco#29
@acevif acevif mentioned this pull request Aug 6, 2024
stephencelis pushed a commit that referenced this pull request Aug 6, 2024
- Fixed typo introduced in PR #29
@honus
Copy link

honus commented Nov 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants