Re: Can't use +initialize, now what?
Re: Can't use +initialize, now what?
- Subject: Re: Can't use +initialize, now what?
- From: Greg Parker <email@hidden>
- Date: Wed, 29 Mar 2017 13:50:54 -0700
> On Mar 29, 2017, at 10:52 AM, Quincey Morris <email@hidden> 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@hidden <mailto:email@hidden> Runtime Wrangler
_______________________________________________
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