-
Notifications
You must be signed in to change notification settings - Fork 166
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
use ReentrantLock instead of NSRecursiveLock
- Loading branch information
Showing
1 changed file
with
5 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
d9b2502
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.
Johann, since this is changing the return type, I think it should have been marked as deprecated first and the change to be done later?
d9b2502
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.
You think someone could be using this lock object in his own code? Seems quite improbable. The important methods lock(), tryLock() and unlock() exist in both classes.
Would you defer that change to Wonder 6.0? Even if we deprecate the object, we will have to switch from the one to the other without a transition time where botch objects are usable.