Comments on: Core Data and Multi-threading http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/ objective-c and c++ code for the mac Fri, 05 Dec 2008 09:07:45 +0000 http://wordpress.org/?v=2.5 By: Scott Stevenson http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-587 Scott Stevenson Fri, 20 Oct 2006 21:15:47 +0000 http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-587 <i>Core Data can make something part of the equation</i> Wow. Something got mixed up there. It should have read "can make some part of the equation easier". Core Data can make something part of the equation

Wow. Something got mixed up there. It should have read “can make some part of the equation easier”.

]]> By: Scott Stevenson http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-586 Scott Stevenson Fri, 20 Oct 2006 21:14:41 +0000 http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-586 <i>Finally, Core Data is not really a good choice for an NNTP server, but you will find out</i> I don't agree with that. No matter how you slice it, Core Data can make something part of the equation. If you don't want to use its persistence engine, you can opt out of that and just use it for change tracking and UI population. Core Data's speed can be extremely competitive with raw SQLite if used properly, which was explained at one session at WWDC. Finally, Core Data is not really a good choice for an NNTP server, but you will find out

I don’t agree with that. No matter how you slice it, Core Data can make something part of the equation. If you don’t want to use its persistence engine, you can opt out of that and just use it for change tracking and UI population.

Core Data’s speed can be extremely competitive with raw SQLite if used properly, which was explained at one session at WWDC.

]]> By: Andy http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-528 Andy Tue, 17 Oct 2006 01:42:32 +0000 http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-528 Hi Jakob, I do know about CFSocket/NSStream and NSRunLoop, etc. The main reason for wanting to use kqueue is the same reason for wanting to use Core Data in Wombat. That is, I've never used kqueue before and wanted to learn. I've also heard that kqueue is much more efficient/scalable that select. I'm not sure what NSRunLoop/CFRunLoop uses; it might use kqueue behind the scenes making my direct use of kqueue rather pointless. Hi Jakob,

I do know about CFSocket/NSStream and NSRunLoop, etc. The main reason for wanting to use kqueue is the same reason for wanting to use Core Data in Wombat. That is, I’ve never used kqueue before and wanted to learn.

I’ve also heard that kqueue is much more efficient/scalable that select. I’m not sure what NSRunLoop/CFRunLoop uses; it might use kqueue behind the scenes making my direct use of kqueue rather pointless.

]]> By: Chris Hanson http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-518 Chris Hanson Mon, 16 Oct 2006 14:30:57 +0000 http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-518 You can use a SQLite persistent store from multiple Core Data persistence stacks (coordinators) at once, whether they're in the same or multiple processes. As Jakob pointed out, depending on your filesystem and its locking support, this can place limits on your performance; however, on a local filesystem, SQLite should be using byte-range locking rather than simple file locking. You should be able to see this yourself from the public SQLite source code. You're also absolutely correct about having to lock a context any time you access or manipulate its managed objects. As a convenience, you don't have to do this if (a) you create the context in the same thread as you use it and (b) you use it (and its object graph) only in that thread. The practical upshot of the above is as you discovered, that you can use multiple contexts to achieve your goals. Here's a good article explaining why all of the above is the case by Ben Trumbull; it's from the WebObjects list and covers EOEditingContext, which is the spiritual forebear of NSManagedObjectContext: http://lists.apple.com/archives/Webobjects-dev/2004/Dec/msg00255.html You can use a SQLite persistent store from multiple Core Data persistence stacks (coordinators) at once, whether they’re in the same or multiple processes. As Jakob pointed out, depending on your filesystem and its locking support, this can place limits on your performance; however, on a local filesystem, SQLite should be using byte-range locking rather than simple file locking. You should be able to see this yourself from the public SQLite source code.

You’re also absolutely correct about having to lock a context any time you access or manipulate its managed objects. As a convenience, you don’t have to do this if (a) you create the context in the same thread as you use it and (b) you use it (and its object graph) only in that thread. The practical upshot of the above is as you discovered, that you can use multiple contexts to achieve your goals. Here’s a good article explaining why all of the above is the case by Ben Trumbull; it’s from the WebObjects list and covers EOEditingContext, which is the spiritual forebear of NSManagedObjectContext: http://lists.apple.com/archives/Webobjects-dev/2004/Dec/msg00255.html

]]> By: Jakob Stoklund Olesen http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-502 Jakob Stoklund Olesen Sun, 15 Oct 2006 11:08:40 +0000 http://www.losingfight.com/blog/2006/10/14/core-data-and-multi-threading/#comment-502 Andy, SQLite does in fact allow multiple processes to edit a database at the same time, and it works too. It uses file-level locking to do this, so performance is less than stellar if you have many processes. One thing you need to consider when doing multithreaded Core Data is that changes are not processed automatically outside the GUI thread. You need to regularly save, fetch, or call -processPendingChanges manually. Another thing: when using multiple contexts, you need to use -refreshObject:mergeChanges: to keep contexts up to date. This is the only way of propagating changes between existing contexts. As for multiplexing sockets, do you know about CFSocket and NSStream? kqueue is pretty low level, not that there is anything wrong with that. Finally, Core Data is not really a good choice for an NNTP server, but you will find out :-) Andy,

SQLite does in fact allow multiple processes to edit a database at the same time, and it works too. It uses file-level locking to do this, so performance is less than stellar if you have many processes.

One thing you need to consider when doing multithreaded Core Data is that changes are not processed automatically outside the GUI thread. You need to regularly save, fetch, or call -processPendingChanges manually.

Another thing: when using multiple contexts, you need to use -refreshObject:mergeChanges: to keep contexts up to date. This is the only way of propagating changes between existing contexts.

As for multiplexing sockets, do you know about CFSocket and NSStream? kqueue is pretty low level, not that there is anything wrong with that.

Finally, Core Data is not really a good choice for an NNTP server, but you will find out :-)

]]>