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.
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.
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.
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.PthreadLockbe backed by error checking mutexes. Mitigate #508 in a different way.Checklist