Re: [[NSFileManager alloc] init] considered thread-safe
Re: [[NSFileManager alloc] init] considered thread-safe
- Subject: Re: [[NSFileManager alloc] init] considered thread-safe
- From: Quincey Morris <email@hidden>
- Date: Tue, 4 May 2010 15:48:20 -0700
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 (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