-
Notifications
You must be signed in to change notification settings - Fork 355
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
Implement the os_unfair_lock
functions on macOS
#3745
Conversation
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.
libc::os_unfair_lock_assert_not_owner(lock.get()); | ||
} | ||
|
||
// `os_unfair_lock`s can be moved and leaked: |
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.
What if they get moved while being locked?
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.
Nothing, the lock continues to function. We can in all likelihood rely on this, because the lock is unlocked in userspace before entering the kernel, which means the kernel cannot rely on the lock being present when doing the wake, as another thread might lock, unlock and deallocate it immediately. And as the userspace code cannot rely on the lock being fixed either – the structure is too small to contain a pointer – we can do all the moving and leaking we like.
Looks good, thanks a lot! I also filed #3749 to track adjusting our shared lock implementations so that they can be address-sensitive the way they should be. Please squash the commits. |
I could change this to use the futex API like the real implementation, which would make this behave exactly the same way. |
@bors r+
That seems a bit awkward to implement inside Miri... also, we'd want to raise UB when doing things that are not guaranteed by the implementation, so having exactly the same implementation does not seem quite right. |
☀️ Test successful - checks-actions |
These are needed for rust-lang/rust#122408. See the documentation here and the implementation here.