Asserting when CoreData thread debugging is enabled #24

Closed
opened 2025-12-29 15:22:28 +01:00 by adam · 3 comments
Owner

Originally created by @JoeMatt on GitHub (Dec 18, 2015).

When activating the CoreData launch flag -com.apple.CoreData.ConcurrencyDebug 1 all of the included tests assert at the first managed object creation attempt.

Originally created by @JoeMatt on GitHub (Dec 18, 2015). When activating the CoreData launch flag `-com.apple.CoreData.ConcurrencyDebug 1` all of the included tests assert at the first managed object creation attempt.
adam closed this issue 2025-12-29 15:22:29 +01:00
Author
Owner

@JohnEstropia commented on GitHub (Dec 18, 2015):

Thanks for the feedback!

Yup, this is expected to happen. The com.apple.CoreData.ConcurrencyDebug flag lets Core Data tell you when the managed context is accessed from any queue other than its own, which includes CoreStore's transactions' queues (beginAsynchronous(), etc).

CoreStore already guarantees safety for you by making the Main Context read-only, and by only allowing updates to be made within transactions. You should be safe even without the ConcurrencyDebug flag (as long as you don't do hacky things).

I'll close this for now but feel free to ask if you have other questions :)

@JohnEstropia commented on GitHub (Dec 18, 2015): Thanks for the feedback! Yup, this is expected to happen. The `com.apple.CoreData.ConcurrencyDebug` flag lets Core Data tell you when the managed context is accessed from any queue other than its own, which includes CoreStore's transactions' queues (`beginAsynchronous()`, etc). CoreStore already guarantees safety for you by making the Main Context read-only, and by only allowing updates to be made within transactions. You should be safe even without the ConcurrencyDebug flag (as long as you don't do hacky things). I'll close this for now but feel free to ask if you have other questions :)
Author
Owner

@JoeMatt commented on GitHub (Dec 18, 2015):

Would storing the managed object returned from a synchronous fetch as a Swift computed property be "hacky"

Trying to debug why we see random faults and that's about the strangest thing I think we're doing.

@JoeMatt commented on GitHub (Dec 18, 2015): Would storing the managed object returned from a synchronous fetch as a Swift computed property be "hacky" Trying to debug why we see random faults and that's about the strangest thing I think we're doing.
Author
Owner

@JohnEstropia commented on GitHub (Dec 18, 2015):

Do you mean something like this?

self.object = CoreStore.fetchOne(...) // or datastack.fetch...

If so then it should be fine.

I'm also curious what you meant by "random faults". If you are editing the object from inside a transaction, the object stored in the property is expected to refetch its new values (and is probably what you are observing).

@JohnEstropia commented on GitHub (Dec 18, 2015): Do you mean something like this? ``` swift self.object = CoreStore.fetchOne(...) // or datastack.fetch... ``` If so then it should be fine. I'm also curious what you meant by "random faults". If you are editing the object from inside a transaction, the object stored in the property is expected to refetch its new values (and is probably what you are observing).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/CoreStore#24