> On Mar 29, 2017, at 10:52 AM, Quincey Morris > <[email protected]> wrote: > > Incidentally, there have always been other problems with using +initialize. > You don’t know how many times it will be called, since it’s called once for > each class, and it may be inherited from class to subclass. You have to code > defensively against multiple initializations. Also, I don’t think there are > any thread safety guarantees, so that’s more defensive coding. Swift’s lazy > static initializations are guaranteed to happen once, and to be thread-safe.
+initialize has strong thread-safety guarantees. All superclass +initialize are guaranteed to complete before any subclass +initialize begins. While one thread is running some class's +initialize, all other threads that attempt to send a message to that class will block until +initialize completes. These guarantees can lead to deadlocks. For example, if two classes each have a +initialize method that tries to use the other class then you might get stuck with each one waiting for the other to complete. Beware of +initialize methods that do too much work. In recent OS versions the runtime puts specially-named stack frames into your backtrace which can help identify when +initialize deadlock occurs: `_WAITING_FOR_ANOTHER_THREAD_TO_FINISH_CALLING_+initialize` and `_CALLING_SOME_+initialize_METHOD`. Environment variable OBJC_PRINT_INITIALIZE_METHODS=YES logs some details of +initialize processing that can also help. -- Greg Parker [email protected] <mailto:[email protected]> Runtime Wrangler _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
