Re: Are there any NSUserDefaults keys which aren't valid?
Re: Are there any NSUserDefaults keys which aren't valid?
- Subject: Re: Are there any NSUserDefaults keys which aren't valid?
- From: Jonathan del Strother <email@hidden>
- Date: Sat, 28 Jan 2006 11:21:44 +0000
On 26 Jan 2006, at 22:35, Derrick Bass wrote:
On Jan 26, 2006, at 1:32 PM, j o a r wrote:
On 26 jan 2006, at 20.20, John Stiles wrote:
@synchronized may not be a sufficient workaround. When the AppKit
docs say that something isn't thread-safe, you are required to
run it on the main thread. Violate that contract and you are in
"unspecified behavior" territory.
Absolutely true! But, like was pointed out in the other thread on
this topic a few days ago:
I don't understand why people keep saying this. Is the following
documentation simply incorrect?
From <http://developer.apple.com/documentation/Cocoa/Conceptual/
Multithreading/articles/CocoaSafety.html> we have:
"The classes and functions in the following table are generally
considered to be thread-safe. You can use them from multiple
threads without first acquiring a lock."
and
"The classes and functions in the following table are generally not
thread-safe. Some of these items may be made thread-safe in the
future but for now you should use a lock or the @synchronized
directive if there is a potential for access by multiple threads.
For some objects, like NSAppleScript, you should use the object
only from your application’s main thread. Check the class
documentation to see if any additional guidelines are available."
Well, FWIW, I've been doing my very best to break threaded
NSUserDefaults, and haven't succeeded yet. I've been running
multiple threads with tight loops that read and write bunches of junk
to NSUserDefaults, and it seems to handle them just fine. I only
have a single processor machine - I guess there could be some
subtlety that might crop up on dual processors, and AppKit wasn't
doing much in the background with my test app, but it appears to work
so far.
None of which proves much, unfortunately. Would be nice to get a
definitive Apple answer on this...
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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