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

Add a primitive storage for managing critical state and platform abstracted locking #7

Merged
merged 1 commit into from
Jan 14, 2022

Conversation

phausler
Copy link
Member

This is a pre-requisite for managing state for backing storage that cannot be managed as an actor (due to cancellation). Locking is heavily inspired from the cross platform implementation in swift-corelibs-foundation (but skipping the try lock and the recursive variant).

ManagedCriticalState is an abstraction around that locking primitive in addition controlling mutations to a stored value. This allows for transactions from multiple queues/actors/threads to shared state without requiring the memory layout of the stored value to fit into an atomic intrinsic.

With the state of withTaskCancellationHandler this becomes distinctly important for the cancel closure since that is NOT asynchronous and therefore cannot be meaningfully used with an actor. There is additional utility that this type could provide to non async/await code and perhaps should be considered for refinement into the standard library. (we seem to need this pattern a lot...)

Copy link

@jmschonfeld jmschonfeld left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall 👍🏻

@phausler phausler merged commit 2b4f602 into main Jan 14, 2022
@phausler phausler deleted the pr/locking branch January 14, 2022 00:18
platformLock.deinitialize(count: 1)
}

fileprivate static func lock(_ platformLock: PlatformLock) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just out of curiosity, why do you prefer storing the primitive and calling these static versions, instead of just storing a Lock instance and calling $0.lock()?

Copy link
Member Author

@phausler phausler Jan 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the issue with storing a lock is that first off should be a move only type (and we don't have that yet). and second off we need to have some sort of de-initialization of it (triggered by the deallocation of the managed buffer)

Lock itself is useful when you do have it separated out rather than just in use for the managed critical state. so this way we funnel everything to the same source of truth.

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.

None yet

4 participants