.beginAsynchronous will check for main thread #4

Closed
opened 2025-12-29 15:21:52 +01:00 by adam · 1 comment
Owner

Originally created by @SteveKChiu on GitHub (Jul 9, 2015).

I am not sure why this assert is needed, as the code show it immediately jump to different queue.

This is what I am doing, I fetch json from server in different queue; upon completion I call .beginAsynchronous to start transaction to store the object, and at that time the queue is NOT main queue.

So my question is whether it is absolutely necessary to call .beginAsynchronous in the main thread? Or we can remove this assertion?

Originally created by @SteveKChiu on GitHub (Jul 9, 2015). I am not sure why this assert is needed, as the code show it immediately jump to different queue. This is what I am doing, I fetch json from server in different queue; upon completion I call .beginAsynchronous to start transaction to store the object, and at that time the queue is _NOT_ main queue. So my question is whether it is absolutely necessary to call .beginAsynchronous in the main thread? Or we can remove this assertion?
adam added the enhancementfixed labels 2025-12-29 15:21:52 +01:00
adam closed this issue 2025-12-29 15:21:53 +01:00
Author
Owner

@JohnEstropia commented on GitHub (Jul 9, 2015):

@SteveKChiu You're right, they are completely unnecessary and should be thread-safe without them. There's probably a couple more places where thread checks are overprotective, but I'll remove the ones from the beginXXXX() methods. Thanks!

@JohnEstropia commented on GitHub (Jul 9, 2015): @SteveKChiu You're right, they are completely unnecessary and should be thread-safe without them. There's probably a couple more places where thread checks are overprotective, but I'll remove the ones from the `beginXXXX()` methods. Thanks!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/CoreStore#4