Re: Cross-user and cross-process shared settings
Re: Cross-user and cross-process shared settings
- Subject: Re: Cross-user and cross-process shared settings
- From: Dave Keck <email@hidden>
- Date: Wed, 26 Aug 2009 13:39:36 -1000
> I've tried reading and writing an XML file directly, and I can get this to
> work fine with multiple threads (via a simple NSLock), but when I attempt to
> apply an O_EXLOCK to the file to prevent one process from writing to the
> file while the other is, but it doesn't seem to be working.
How doesn't it work?
The O_EXLOCK flag applies an advisory lock to the file. It's not
enforced by the OS - other processes are free to ignore the lock and
write to the file.
Anyway, I recently wrote some code along the lines of what you're
trying to do. (I plan on open-sourcing it before long - I'll announce
it on this list when the code's available.) Here's some notes on how I
went about it:
When changing a property in the preferences I used a simple
transaction mechanism that acquires a lock by creating a lock file,
blocking if another process already holds the lock. Once it acquires
the lock, it first reads the preferences file to update its caches to
prevent old settings from being written. Once updated, it changes the
property in the in-memory cache, and writes the cache to disk.
Finally, it releases the lock.
Reading the preferences is similar: acquire the lock, read preferences
from disk, release the lock. This forces the current process to delay
updating its cache until other processes have finished making their
changes to the preferences file.
This technique works great if one process is writing a file, and
another process is reading it. It also works well if two processes are
writing to the preferences file, if the two processes' changes don't
conflict - that is, process A changes the "AlarmTime" property and
process B changes the "AlarmActions" property. If both processes are
changing the "AlarmActions" property, then which one exists on-disk of
course depends on which process changed the property last.
Hope that helps.
_______________________________________________
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