On Oct 31, 2011, at 5:30 PM, cocoa-dev-requ...@lists.apple.com wrote: > Date: Mon, 31 Oct 2011 17:27:10 -0700 > From: Jens Alfke <j...@mooseyard.com> > Subject: Is NSDateFormatter thread-safe? > > I have some code that uses a shared NSDateFormatter instance to convert dates > to/from ISO-8601 format. This code is now being invoked on multiple threads, > and I‚m getting intermittent malloc warnings about double frees, and one > actual crash. > My assumption was that an NSDateFormatter should be thread-safe as long as I > treat it as read-only (not changing any attributes) but this makes me think > I‚m wrong.
Short answer: NSDateFormatter is not thread-safe now even for that usage, but it will be more thread-safe in the future. http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html does list NSDateFormatter in the thread-unsafe classes, about which it says "The following classes … are generally not thread-safe. In most cases, you can use these classes from any thread as long as you use them from only one thread at a time." In particular, the ICU functions udat_format and udat_parse, which implement some of the NSDateFormatter functionality, lie when they claim their UDateFormat * parameter is const. In fact they modify the Calendar object owned by the UDateFormat object, setting it to the date to format or to the parsed date. There is an ICU ticket to fix this which will make these functions more thread-safe: http://bugs.icu-project.org/trac/ticket/8844 - Peter E (who owns that ICU ticket) _______________________________________________ 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
