-
Notifications
You must be signed in to change notification settings - Fork 429
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
Always use error checking pthread mutex. #654
Conversation
Sources/Atomic.swift
Outdated
@@ -187,6 +181,15 @@ internal class Lock { | |||
case EBUSY: | |||
return false | |||
default: | |||
#if DEBUG && arch(arm) |
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.
It looks like EAGAIN
will be silently allowed when DEBUG
, but will lead to an assertion failure when !DEBUG
.
I wonder if it should be the other way around? I usually set DEBUG
in builds where I want more assertions.
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 guess at this point we should just treat EAGAIN
as EBUSY
. Just found this issue: ReactiveCocoa/ReactiveCocoa#3598.
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.
The weirdest thing is that based on the libpthread implementation only the recursive lock can return EAGAIN
, and it holds for implementations since El Capitan GM. All the reported issues do not seem to involve properties which are the only thing using recursive locks in ReactiveSwift.
Just found out that on Darwin 11 was |
Resolves #652 and ReactiveCocoa/ReactiveCocoa#3598.
Make all
Lock.PthreadLock
be backed by error checking mutexes. Mitigate #508 in a different way.Checklist