views:

141

answers:

3

What am I trying to do?

  1. A UI process that reads data from a Core Data store on disk. It wouldn't need to edit the data, just read and display the data.

  2. A command line process that writes to the same data store as accessed by the UI.

Why?

So that the command line process can be running all the time but the user can quit the UI process and forget about the app until they need to look at the data it's captured.

What would be the simplest and most reliable way of achieving this?

What Have I Tried?

I've read up on sharing a data store between threads and implemented this once before, but I can't find anything in the docs or on the web indicating how to share a store between processes.

Is it as simple as pointing both processes at the same data store file? I've experimented with this briefly. It appeared to work OK, but I'm worried I might run into problems with locking etc when it's really put under stress.

Finally

I'd really appreciate someone giving me pointers on what direction to go with this. Thanks.

+2  A: 

This might be one of those situations in which you'll simply have to Try It And See™.

Insofar as I can remember, SQLite (which is the data store you'll most likely want to be using) has built in mechanisms for file locking and so on; so the integrity of the file is likely to be assured. If, on the other hand, you use the CoreData/XML approach, you might run into problems.

In other words; use the SQLite backing for your file, and you should likely be fine.

Williham Totland
+1  A: 

You need to re-think your architecture. If you want a daemon to own the data store, then have your GUI app connect to the daemon. Trying to share the data store is a can of worms you don't want to open.

NSResponder
That isn't necessarily true. A SQLite based persistent Core Data store will work fine as long as there aren't a bazillion write operations / second from the daemon.
bbum
And since I have literally 12 saves every 3 seconds, I think that qualifies as less than "a bazillion"! :)
John Gallagher
+1  A: 

You can do exactly what you want, you probably want to use the SQLite store otherwise saving and committing every time you want to synch out data will be horrifically slow. You just need to use some sort of IPC doorbell between the apps so that you can inform one app it needs to recheck the persistent store on disk and merge in its data.

Apple documents using multiple persistent store corindators as a valid option in Multi-Threading with Core Data (in "General Guidelines", open 2). That happens to be discussing completely parallel CD stacks in the same process, but it is valid if they are in completely separate address spaces as well.

Louis Gerbarg
Thanks. That's really helpful. I assume to pass data between the processes I'd use NSDistributedNotificationCenter or Distributed Objects. I'm leaning towards the latter.http://stackoverflow.com/questions/504122/best-practices-for-passing-data-between-processes-in-cocoa
John Gallagher
Sure, but if everything is passing through the persistent store you just save: in one process, send a notification, and in the other app bring the persistence stack up to date. Checkout http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/CoreData/Articles/cdUsingMOs.html#//apple_ref/doc/uid/TP40001803-208900
Louis Gerbarg
You could use either distributed notifications, a kqueue, or a dispatch_source to monitor the sqlite store file for modifications. Just don't poll.
bbum
@Louis Great. Thanks for the link. That's pretty much what I was thinking of doing.@bbum Great. Thanks for the extra suggestions.
John Gallagher