Jens is exactly right. If you are going to use the delegate, you must make your own instance of NSFileManager. Clearly - if you did that with the shared manager, you and other threads would fight over it.
NSFileManager is otherwise threadsafe. There's an open bug to rev the docs. -Ken On Tue, May 4, 2010 at 3:48 PM, Quincey Morris <quinceymor...@earthlink.net>wrote: > On May 4, 2010, at 15:09, Jens Alfke wrote: > > >> 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? > > > > The latter, I think. > > That's what I was starting to think too, except for the *absolute* > assertion to the contrary in the Threaded Programming Guide, which I quoted > before: > > > http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html > > > 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) > > That's pretty clear. Unless it's wrong. > > >> 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? > > > > Because then you wouldn't be able to set a delegate on the shared > instance and have it be used on all calls involving that instance (which is > the most common case.) > > Well, you can't set a delegate on *any* instance if anything else might > also do so. So that explains why there can be multiple instances, not why > the default instance isn't as thread-safe as the others (if it isn't, and if > they are). > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/kenferry%40gmail.com > > This email sent to kenfe...@gmail.com > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
