This repository has been archived by the owner on Dec 19, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6
Core data operation without semaphores #85
Merged
lukestringer90
merged 3 commits into
3Squared:master
from
lukestringer90:core-data-operation-without-semaphores
Sep 2, 2016
Merged
Core data operation without semaphores #85
lukestringer90
merged 3 commits into
3Squared:master
from
lukestringer90:core-data-operation-without-semaphores
Sep 2, 2016
Conversation
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
No longer uses semaphores. The operation merges the contexts then completes itself while on the main thread. I haven't observed any problems with this, but added a comment for future reference incase it does.
Deprecated the `completeOperationBySavingContext:` method in favour of a simpler `completeAndSave`, that doesn't take a context and uses it's own private context instead. `completeOperationBySavingContext:` is marked as deprecated, and if called calls `completeAndSave` internally anyway.
self.managedObjectContextToMerge.shouldMergeOnSave = NO; | ||
|
||
[self.managedObjectContextToMerge performBlockAndWait:^{ | ||
[self performWorkWithPrivateContext:self.managedObjectContextToMerge]; | ||
}]; | ||
} | ||
|
||
- (BOOL)isConcurrent |
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'm not sure if you should have both isConcurrent
and isAsynchronous
, but as long as they agree it should be okay.
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.
How about:
- (BOOL)isConcurrent
{
return [self isAsynchronous];
}
- (BOOL)isAsynchronous
{
return YES;
}
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.
That should work.
* Note: we are now on the main thread when we finish the opreation. | ||
* Not sure if finishing the operation (thus triggering the KVO notifications) | ||
* on a different thread (main thread) to the operation's execution causes | ||
* problems. Seems fine but might not be ¯\_(ツ)_/¯ |
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.
¯_(ツ)_/¯
This was referenced Sep 2, 2016
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Removes use of semaphores which attempted to ensure an operation was completed on the same thread it was executing in. This has been removed as occasionally the semaphore was not signalled properly, and after some investigation nothing bad seems to happen from completing the operation on the main thread.
This is an alternative to @CaptainRedmuff's fix in pr #83 for issue #84. The benefit of the approach taken here is that the operation is still responsible for merging the contexts, and therefore can ensure it is only completed once the merge has finished. In #83 the operation completes and lets the context manger handle the merge, which could result in the changes not being merged into the context before another operation starts that is dependent on them being there.