-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Isolated synchronous deinit and asynchronous deinit #2035
Isolated synchronous deinit and asynchronous deinit #2035
Conversation
proposals/0371-isolated-synchronous-deinit-and-asynchronous-deinit.md
Outdated
Show resolved
Hide resolved
- synchronous deinit is nonisolated by default - async deinit - attribute to control task-local usage
b342f55
to
56ef108
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates, I think this looks good and let's ask the @swiftlang/language-steering-group to schedule another review round :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few editorial notes!
class Bar { | ||
@SecondActor | ||
deinit {} // Isolated on SecondActor | ||
If containing class is not isolated, it is still possible to use global actor attribute on `deinit`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If containing class is not isolated, it is still possible to use global actor attribute on `deinit`. | |
If the containing type is not isolated, it is still possible to use a global actor attribute on `deinit`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to use type
to avoid giving false impression that this feature can be used with move-only value types.
|
||
### Isolated deinit of default actors | ||
For isolated synchronous `deinit`, this cost increases. For each class in the hierarchy `swift_task_deinitOnExecutor()` will be called, but slow path can be taken only for the most derived class. Other classes in the hierarchy would be doing redundant actor checks. To avoid this, isolated deinit bypasses Objective-C runtime when calling isolated `deinit` of Swift base classes, and calls `__isolated_deallocating_deinit` directly. Compatibility with Objective-C is preserved only on Swift<->Objective-C boundary in either direction. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is also a bit implementation-y, any way we could rephrase in terms of the actual language model?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reworded a bit, but it still contains mentions __isolated_deallocating_deinit
.
Second iteration of the proposal: