[[NSFileManager alloc] init] considered thread-safe
[[NSFileManager alloc] init] considered thread-safe
- Subject: [[NSFileManager alloc] init] considered thread-safe
- From: Quincey Morris <email@hidden>
- Date: Tue, 4 May 2010 14:03:47 -0700
The documentation for NSFileManager contains this curious statement:
> In Mac OS X v 10.5 and later you should consider using [[NSFileManager alloc] init] rather than the singleton methoddefaultManager. Instances of NSFileManager are considered thread-safe when created using [[NSFileManager alloc] init].
This makes me wonder:
1. Why are the additional instances only "considered" thread-safe. Doesn't anyone know?
2. What does "thread-safe" mean in this context? I would take it to mean that *any* single instance allocated with [[NSFileManager alloc] init] can be used by *any* thread. Or does it mean that each thread needs a unique instance, but such instances happily co-exist?
3. If any single instance allocated with [[NSFileManager alloc] init] is thread-safe in the fullest sense, why doesn't [NSFileManager defaultManger] just return one of these, so that it can be (considered) thread-safe too?
The Leopard release notes don't shed much light.
I did find this thread from 2008:
http://www.omnigroup.com/mailman/archive/macosx-dev/2008-June/061392.html
which appears to say the documentation is wrong. It appears to say that instances are not thread-safe, but can safely be used by one thread at a time.
I also found this in the Threaded Programming Guide:
> Thread-Safe Classes
>
> The following classes and functions are generally considered to be thread-safe. You can use the same instance from multiple threads without first acquiring a lock.
>
> [...]
> • NSFileManager (in Mac OS X v10.5 and later)
which contradicts that thread.
Anyone in the know got confirmation/answers on this? (I only care about 10.5 and later.)
_______________________________________________
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