• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data nested managed object contexts and frequent deadlocks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data nested managed object contexts and frequent deadlocks


  • Subject: Re: Core Data nested managed object contexts and frequent deadlocks
  • From: Michael Link <email@hidden>
  • Date: Fri, 13 Jan 2012 17:01:36 -0600

On Jan 13, 2012, at 3:45 PM, Chris Hanson wrote:

> On Jan 13, 2012, at 12:39 AM, Michael Link wrote:
>
>> the docs seem to indicate that using a main thread concurrency type MOC on the main thread without performBlock: is fine.
>
> It is, otherwise you couldn't (say) bind to a managed object you fetched via a main-queue context on OS X.  What OS version(s) are you seeing this with?

iOS 5.0 on simulator and iOS 5.0.1 on iPhone.

>
>> It appears that the private queue is waiting on the PSCs lock which the child context on the main thread has already locked. It appears that the child context (while holding the PSCs lock) is trying to dispatch_sync to the parent context and thus they are both waiting for each other.
>>
>> Is PriveQueue -> MainQueue a supported configuration? It seems most people still have the parent context on the main thread.
>
> Using a parent private-queue context and a child main-queue context is actually a good design.  I'm not sure about your deadlock; does it still occur if you don't use -performBlock: on your main-queue context but just interact with it directly?

Yes, in exactly the same way. I'm starting to think the problem is with NSFetchedResultsController which is always stuck at performFetch: when these deadlocks occur. Most of the time it will be stuck trying to fault in an object as a result of asking for it's section name. As a test I tried to reproduce what the FRC does and performed the executeFetchRequest: and then iterated through the results asking each object for it's section name. And this doesn't cause a deadlock. If I leave the FRC to do performFetch: after I do my test it will still deadlock there. I'm 99% sure that the FRC has a synchronization problem with nested contexts.

--
Michael_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Core Data nested managed object contexts and frequent deadlocks (From: Michael Link <email@hidden>)
 >Re: Core Data nested managed object contexts and frequent deadlocks (From: Chris Hanson <email@hidden>)

  • Prev by Date: Re: Core Data nested managed object contexts and frequent deadlocks
  • Next by Date: Re: Child windows appear to move when entering full-screen mode / how to detect full-screen transition
  • Previous by thread: Re: Core Data nested managed object contexts and frequent deadlocks
  • Next by thread: TBXML question
  • Index(es):
    • Date
    • Thread