Re: Coredata and threads
Re: Coredata and threads
- Subject: Re: Coredata and threads
- From: Jeff LaMarche <email@hidden>
- Date: Tue, 3 Jan 2006 21:38:36 -0500
Todd:
I haven't been able to find much information on the "thread-safeness"
of Core Data, but I'll tell you what I think based on my experiences,
but with a disclaimer that some of this is probably wrong. I'm still
fumbling around in the dark on one threaded Core Data application I'm
working on and it ain't pretty ;-)
What I think is the case is that Core Data is technically thread
safe. It conforms with NSLocking, and behind the scenes does not keep
SQLite or file handle connections open any longer than necessary.
However, I think that KVO/KVC actions happen on the thread from which
they are triggered, so you could very easily end up with unreleased
objects still in your pool when you release it at the end of your
thread if you aren't very careful about what you do in your thread.
I think the safest thing is to create a new managed object context in
your thread and avoid using any existing controllers or anything that
might trigger something unexpected. When you've got something that
might trigger a KVO notification, call it on the main thread.
Jeff
P.S. I sure hope that someone smarter than me on this subject will
correct any bad information I might have given here
On Jan 3, 2006, at 7:11 PM, Todd Freese wrote:
I have a Core Data Doc-style application in which I need to add
records from another thread using the
insertNewObjectForEntityForName method. Do I need to create another
ManagedObjectContext? Or can I use [self managedObjectContext]? The
main thead has a bound NSArrayController/NSTableView. No sure the
best thread safe way to do this...
Is there any Core Data documentation regarding theading issues? I
seemed to have missed it.
Thanks,
Todd Freese
The Filmworkers Club
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden