PLWeakCompatibility 源码导览（下）

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2012-06-01-a-tour-of-plweakcompatibility-part-ii.html

Last time, I discussed the basics of PLWeakCompatibility in terms of the motivation, the basic hooks used to get the compiler to call our code when handling __weak variables, and calling through to the original implementations where available. Today, I’m going to discuss the implementation of the zeroing weak reference facility that gets used when the runtime doesn’t supply its own __weak support.

RecallThe functions implemented by PLWeakCompatibility which are called directly by the compiler’s generated code are:

1
    PLObjectPtr objc_loadWeakRetained(PLObjectPtr *location);
2
    PLObjectPtr objc_initWeak(PLObjectPtr *addr, PLObjectPtr val);
3
    void objc_destroyWeak(PLObjectPtr *addr);
4
    void objc_copyWeak(PLObjectPtr *to, PLObjectPtr *from);
5
    void objc_moveWeak(PLObjectPtr *to, PLObjectPtr *from);
6
    PLObjectPtr objc_loadWeak(PLObjectPtr *location);
7
    PLObjectPtr objc_storeWeak(PLObjectPtr *location, PLObjectPtr obj);

Where PLObjectPtr is just a typedef for void * and used as a way to prevent ARC from inserting memory management code into these functions where it’s definitely not wanted. All of these functions start with code that calls through to the Objective-C runtime’s implementation where available. When the official runtime functions aren’t available, these seven functions are broken down and implemented in terms of three primitive functions:

1
    PLObjectPtr PLLoadWeakRetained(PLObjectPtr *location);
2
    void PLRegisterWeak(PLObjectPtr *location, PLObjectPtr obj);
3
    void PLUnregisterWeak(PLObjectPtr *location, PLObjectPtr obj);

The PLLoadWeakRetained function loads a weak reference out of the given location and either returns a retained reference to the object it contains, or nil. The PLRegisterWeak function registers a particular memory location as a weak reference to the given object, and PLUnregisterWeak removes that registration. The task that remains is then to implement these three functions.

MAZeroingWeakRefThe goal is to make PLWeakCompatibility completely self-contained with its own zeroing weak reference implementation, which would necessarily be somewhat simple. However, we also wanted to make it use MAZeroingWeakRef where available, as the presence of that library in the app probably means that the programmer likes that implementation, and we might as well take advantage of its presence. Thus, the first task is to detect the presence of MAZeroingWeakRef, and then implement the three primitive functions using it, if it’s present.

First, we need a way to detect whether MAZeroingWeakRef is present, and get a reference to the class if so. This is all wrapped up in a simple function that uses NSClassFromString to attempt to fetch the MAZeroingWeakRef class, within a dispatch_once call to minimize the overhead. It also has an extra flag that allows disabling the MAZeroingWeakRef functionality for testing purposes:

1
    static Class MAZWR = Nil;
2
    static bool mazwrEnabled = true;
3
    static inline bool has_mazwr () {
4
        if (!mazwrEnabled)
5
            return false;
6

7
        static dispatch_once_t lookup_once = 0;
8
        dispatch_once(&lookup_once, ^{
9
            MAZWR = NSClassFromString(@"MAZeroingWeakRef");
10
        });
11

12
        if (MAZWR != nil)
13
            return true;
14
        return false;
15
    }

Now code can simply call has_mazwr, and if it returns true, use MAZWR to get a reference to the class.

The strategy for implementing the three primitives using MAZeroingWeakRef is pretty straightforward. Each primitive gets a location where the weak reference is to be stored, and nothing says that this location is required to directly hold a pointer to the weakly referenced object. Thus, we use the passed-in location to store a pointer to a MAZeroingWeakRef instance which in turn references the original object. PLRegisterWeak will simply create a new instance of MAZeroingWeakRef and place it in the given location. PLUnregisterWeak will simply release that instance. And PLLoadWeakRetained can just call through to the object’s -target method.

Each primitive function checks has_mazwr at the top to decide what to do. The beginning of each primitive function contains the MAZeroingWeakRef calls, and they are:

1
    static PLObjectPtr PLLoadWeakRetained(PLObjectPtr *location) {
2
        if (has_mazwr()) {
3
            MAZeroingWeakRef *mazrw = (__bridge MAZeroingWeakRef *) *location;
4
            return objc_retain([mazrw target]);
5
        }
6
        ...
7

8
    static void PLRegisterWeak(PLObjectPtr *location, PLObjectPtr obj) {
9
        if (has_mazwr()) {
10
            MAZeroingWeakRef *ref = [[MAZWR alloc] initWithTarget: obj];
11
            *location = (__bridge_retained PLObjectPtr) ref;
12
            return;
13
        }
14
        ...
15

16
    static void PLUnregisterWeak(PLObjectPtr *location, PLObjectPtr obj) {
17
        if (has_mazwr()) {
18
            if (*location != nil)
19
                objc_release(*location);
20
            return;
21
        }
22
        ...

The Built-In ImplementationNow for the real meat: the built-in zeroing weak reference implementation. The strategy is to swizzle out release and dealloc on target objects. The swizzled release method will add the object to a list of releasing objects, blocking anyone attempting to resolve a weak reference while the release is occurring, ensuring no weak reference can be resolved when an object’s final release triggers its dealloc. The swizzled dealloc method will then clear out all weak references to the object.

The first thing we need is a mutex to protect all of the shared data structures:

1
    static pthread_mutex_t gWeakMutex;

We also need a way to track all of the weak references currently registered for any given object. This comes in the form of a CFMutableDictionary mapping objects to CFMutableSet instances containing the registered weak addresses:

1
    static CFMutableDictionaryRef gObjectToAddressesMap;

We’re likely to see weak references to multiple instances of the same class, so we need to track which classes have been swizzled andavoid swizzling them twice. This is done by tracking the swizzled classes in a set:

1
    static CFMutableSetRef gSwizzledClasses;

The objects that are currently in the middle of a release call are stored in a bag:

1
    static CFMutableBagRef gReleasingObjects;

Since some code needs to wait around for gReleasingObjects to change, that means we also need a condition variable for them to wait on. (If you’re unfamiliar with condition variables, I’ll discuss that more later.)

1
    static pthread_cond_t gReleasingObjectsCond;

Some data also needs to be stored in thread-local storage. Two tables to assist with the swizzling process reside there. They get stored in structs accessed through a pthread thread-local storage key:

1
    static pthread_key_t gTLSKey;

For convenience, we also put all of the selectors necessary for swizzling into global variables:

1
    static SEL releaseSEL;
2
    static SEL releaseSELSwizzled;
3
    static SEL deallocSEL;
4
    static SEL deallocSELSwizzled;

Every primitive function needs to access these variables, and they all need to be initialized before use. This initialization is all wrapped in a dispatch_once:

1
    static void WeakInit(void) {
2
        static dispatch_once_t pred;
3
        dispatch_once(&pred, ^{

The first thing it does is initialize the mutex, using the recursive atribute::

1
            pthread_mutexattr_t attr;
2
            pthread_mutexattr_init(&attr);
3
            pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
4

5
            pthread_mutex_init(&gWeakMutex, &attr);
6

7
            pthread_mutexattr_destroy(&attr);

Next, the map of objects to addresses and the set of swizzled classes are created:

1
            gObjectToAddressesMap = CFDictionaryCreateMutable(NULL, 0, NULL, &kCFTypeDictionaryValueCallBacks);
2

3
            gSwizzledClasses = CFSetCreateMutable(NULL, 0, NULL);

By passing NULL for the dictionary key callbacks and the set callbacks, we ensure that CoreFoundation doesn’t try to do any sort of memory management on them.

The releasing objects set is initialized, as well as the condition variable used to wait on it:

1
            gReleasingObjects = CFBagCreateMutable(NULL, 0, NULL);
2
            pthread_cond_init(&gReleasingObjectsCond, NULL);

Next, the pthread thread-local storage key is created. There’s a bit of paranoia here with the error checking because this function can realistically fail. The number of thread-local storage keys that can be created is limited and relatively small: 512 keys on Mac OS X currently. This should be more than sufficient, but since it can realistically fail, I want it to fail early and obviously:

1
            int err = pthread_key_create(&gTLSKey, DestroyTLS);
2
            if (err != 0) {
3
                NSLog(@"Error calling pthread_key_create, we really can't recover from that: %s (%d)", strerror(err), err);
4
                abort();
5
            }

The DestroyTLS function frees the memory allocated for the thread-local storage. I’ll show its implementation momentarily.

Finally, the selectors are initialized. We can’t use the standard @selector construct for release and dealloc, because this is not allowed with ARC. Instead, we use sel_getUid (the Objective-C runtime equivalent of NSSelectorFromString) to fetch the selectors under ARC’s nose:

1
            releaseSEL = sel_getUid("release");
2
            releaseSELSwizzled = sel_getUid("release_PLWeakCompatibility_swizzled");
3
            deallocSEL = sel_getUid("dealloc");
4
            deallocSELSwizzled = sel_getUid("dealloc_PLWeakCompatibility_swizzled");
5
        });
6
    }

Each primitive function the makes a call to WeakInit before it does anything else, ensuring that all of these variables are set up. I’ll omit that call, as well as the MAZeroingWeakRef code, when discussing the implementation of those functions, just to keep things simple.

Thread-Local StorageA pthread thread-local storage key can be used to set and retrieve a single pointer per thread. To store multiple values, we allocate a struct which contains everything we want to store. We need two dictionaries which help the swizzled methods call through to their original values. Here is the struct:

1
    struct TLS {
2
        // Tables tracking the last class a swizzled method was sent to on an object
3
        CFMutableDictionaryRef lastReleaseClassTable;
4
        CFMutableDictionaryRef lastDeallocClassTable;
5
    };

Since this struct is used in a couple of places, we want a wrapper function that will retrieve it, creating it if on demand if nothing else has used the TLS struct on that thread yet. pthread_getspecific retrieves the current value, and if the current value is NULL, this function uses pthread_setspecific to set a new key:

1
    static struct TLS *GetTLS(void) {
2
        struct TLS *tls = pthread_getspecific(gTLSKey);
3
        if (tls == NULL) {
4
            tls = calloc(1, sizeof(*tls));
5
            tls->lastReleaseClassTable = CFDictionaryCreateMutable(NULL, 0, NULL, NULL);
6
            tls->lastDeallocClassTable = CFDictionaryCreateMutable(NULL, 0, NULL, NULL);
7
            pthread_setspecific(gTLSKey, tls);
8
        }
9
        return tls;
10
    }

We also need a function to destroy the TLS struct. This function was passed to pthread_key_create, and is automatically called by pthread when a thread is destroyed:

1
    static void DestroyTLS(void *ptr) {
2
        struct TLS *tls = ptr;
3
        if (tls != NULL && tls->lastReleaseClassTable) {
4
            CFRelease(tls->lastReleaseClassTable);
5
            CFRelease(tls->lastDeallocClassTable);
6
        }
7
        free(tls);
8
    }

With these in place, any thread can simply call GetTLS() and then manipulate the data in the struct, which is guaranteed to only be visible to the calling thread.

The Primitive FunctionsThe implementation of PLLoadWeakRetained is relatively straightforward. It needs to acquire the global mutex, then retrieve the object pointer. If the object is currently being released, then it must wait until it’s no longer being released.

First thing it does is acquire the global mutex, then try to fetch the value stored at the given location:

1
    static PLObjectPtr PLLoadWeakRetained(PLObjectPtr *location) {
2
        PLObjectPtr obj;
3
        pthread_mutex_lock(&gWeakMutex); {
4
            obj = *location;

Next it checks to see if the given object is in the list of releasing objects. If it’s there, it uses pthread_cond_wait to block on the condition variable, then reloads the location to get the latest value:

1
        while (CFBagContainsValue(gReleasingObjects, obj)) {
2
            pthread_cond_wait(&gReleasingObjectsCond, &gWeakMutex);
3
            obj = *location;
4
        }

pthread_cond_wait releases the given mutex and then waits for somebody to signal the condition variable. Once signalled, it re-acquires the mutex and resumes execution. This allows the thread to block until another thread signals that the table of releasing objects changed, at which point it can re-examine it.

This is a while loop rather than a simple if statement for a couple of reasons. One is simply that the signalled change may not be for this object. There’s a single condition variable for the whole table, and some other object may be the one that got removed.

The other reason is a bit more interesting and is called spurious wakeup. In short, due to various implementation details, pthread_cond_wait may occasionally return even when nothing has signalled on the condition variable. Due to this, any call to pthread_cond_wait should always be wrapped in a loop, not a simple if statement.

Once the object (or nil) is obtained, we simply retain it, release the mutex, and return the retained object.

1
            objc_retain(obj);
2
        }
3
        pthread_mutex_unlock(&gWeakMutex);
4

5
        return obj;
6
    }

PLRegisterWeak is a little more complex. The first thing it does is fetch the set of registered addresses for the given object so it can add the new entry:

1
    static void PLRegisterWeak(PLObjectPtr *location, PLObjectPtr obj) {
2
        pthread_mutex_lock(&gWeakMutex); {
3
            CFMutableSetRef addresses = (CFMutableSetRef)CFDictionaryGetValue(gObjectToAddressesMap, obj);

That set won’t exist if this is the first weak reference to the given object. In that case, this function has to create it:

1
            if (addresses == NULL) {
2
                addresses = CFSetCreateMutable(NULL, 0, NULL);
3
                CFDictionarySetValue(gObjectToAddressesMap, obj, addresses);
4
                CFRelease(addresses);
5
            }

Now that it has the set, the passed-in location is added to it:

1
            CFSetAddValue(addresses, location);

Finally, it calls a helper function to ensure that all of the appropriate swizzling has been done:

1
            EnsureDeallocationTrigger(obj);
2
        } pthread_mutex_unlock(&gWeakMutex);
3
    }

We’ll get into that helper function’s implementation shortly.

The implementation of PLUnregisterWeak is essentially the inverse of PLRegisterWeak, except that it doesn’t have to worry about swizzling, which is simply left in place, and it doesn’t bother to delete the addresses set when it becomes empty:

1
    static void PLUnregisterWeak(PLObjectPtr *location, PLObjectPtr obj) {
2
        pthread_mutex_lock(&gWeakMutex); {
3
            // Remove the location from the set of weakly referenced addresses.
4
            CFMutableSetRef addresses = (CFMutableSetRef)CFDictionaryGetValue(gObjectToAddressesMap, *location);
5
            if (addresses != NULL)
6
                CFSetRemoveValue(addresses, location);
7
        } pthread_mutex_unlock(&gWeakMutex);
8
    }

Let’s look at EnsureDeallocationTrigger’s implementation now. The first thing it does is fetch the class of the given object, and bail out if that class has already been swizzled:

1
    static void EnsureDeallocationTrigger(PLObjectPtr obj) {
2
        Class c = object_getClass(obj);
3
        if (CFSetContainsValue(gSwizzledClasses, (__bridge const void *)c))
4
            return;

If it hasn’t, it then swizzles release and dealloc, using a small helper function, and finally adds the class to the set of swizzled classes:

1
        Swizzle(c, releaseSEL, releaseSELSwizzled, (IMP)SwizzledReleaseIMP);
2
        Swizzle(c, deallocSEL, deallocSELSwizzled, (IMP)SwizzledDeallocIMP);
3

4
        CFSetAddValue(gSwizzledClasses, (__bridge const void *)c);
5
    }

The implementation of Swizzle is simple: it just uses class_addMethod to register the previous IMP under a new selector, and class_replaceMethod to place the new IMP into the original selector:

1
    static void Swizzle(Class c, SEL orig, SEL new, IMP newIMP) {
2
        Method m = class_getInstanceMethod(c, orig);
3
        IMP origIMP = method_getImplementation(m);
4
        class_addMethod(c, new, origIMP, method_getTypeEncoding(m));
5
        class_replaceMethod(c, orig, newIMP, method_getTypeEncoding(m));
6
    }

And that’s just about it. All that remains are the implementations of SwizzledReleaseIMP and SwizzledDeallocIMP. Which, as it turns out, are pretty difficult and complex.

The Subclass ProblemWhen possible, the best way to implement method swizzling is to store the original IMP in a global variable, which you then call as a function pointer:

1
    // original implementation
2
    void (*origIMP)(id, SEL);
3

4
    // swizzle code
5
    origIMP = (void *)method_getImplementation(origMethod);
6
    class_replaceMethod(class, selector, newIMP, method_getTypeEncoding(origMethod));
7

8
    // swizzled IMP
9
    void newIMP(id self, SEL _cmd)
10
    {
11
        // do stuff here
12
        ...
13

14
        // call the original
15
        origIMP(self, _cmd);
16
    }

However, this only works when you’re only swizzling a single class. When swizzling multiple classes, there are multiple original implementations to keep track of. In that case, the best way to do things is to register the original implementation under a new selector on the same class, and look it up that way:

1
    // swizzle code
2
    IMP origIMP = method_getImplementation(origMethod);
3
    class_addMethod(class, @selector(swizzled_method), origIMP, method_getTypeEncoding(origMethod));
4
    class_replaceMethod(class, selector, newIMP, method_getTypeEncoding(origMethod));
5

6
    // swizzled IMP
7
    void newIMP(id self, SEL _cmd)
8
    {
9
        // do stuff here
10
        ...
11

12
        // look up the original
13
        Class class = object_getClass(self);
14
        void (*origIMP)(id, SEL) = (void *)(class_getMethodImplementation(class, @selector(swizzled_method));
15

16
        // call the original
17
        origIMP(self, _cmd);
18
    }

However, this only works if you only swizzle leaf classes. If you ever end up swizzling two classes where one is a superclass of the other, this ends up with infinite recursion and crashes.

To understand why, let’s consider two classes, A and B, both of which override dealloc:

1
    @interface A : NSObject
2
    - (void)dealloc; // clean up stuff
3
    @end
4

5
    @interface B : A
6
    - (void)dealloc; // clean up in aisle three
7
    @end

Let’s assume that we’ve swizzled dealloc on both A and B (presumably because something created a __weak reference to an instance of A and an instance of B). Now something releases an instance of B.

Because of the swizzling, the call to dealloc ends up invoking the swizzled implementation. So far so good.

The swizzled implementation looks up -[B swizzled_dealloc] and calls it. This calls the original implementation of -[B dealloc]. Again, so far so good. At the end of this original implementation, the method will call [super dealloc], which ends up getting -[A dealloc]. Still good up to here.

-[A dealloc] is also the swizzled implementation, but that’s fine. That implementation needs to be reentrant, but it has to be this way if we want to intercept calls to instances of both A and B. The swizzled implementation does its thing again, but is written to tolerate this. Then it calls through to the original implementation. And here is where things go wrong.

Check out the code that looks up the original implementation:

1
    Class class = object_getClass(self);
2
    void (*origIMP)(id, SEL) = (void *)(class_getMethodImplementation(class, @selector(swizzled_method));

Even though this is called from A, object_getClass still returns B. At runtime, there’s no concept of “called from A.” The object’s class is B, and that’s what it gets. So at the end of -[A dealloc], where the swizzled implementation looks up and calls the original, it ends up calling -[B swizzled_dealloc] again! If that method somehow runs a second time without crashing, it will call back to -[A dealloc], which calls back to -[B swizzled_dealloc], and this continues until either some piece of code gets fed up with this abuse, or the infinite recursion runs out of stack space and crashes.

In order to solve this, the swizzled implementation needs some way to know which class it’s attached to. This is trivial using imp_implementationWithBlock to create a slightly different swizzled implementation for each class. Unfortunately, imp_implementationWithBlock is only available on iOS 4.3 and later. Requiring it for PLWeakCompatibility would mean eliminating support for iOS 4.0-4.2, making it much less useful. We need to come up with some other way to handle this.

Emulating superThe hypothetical call to super would walk up the class hierarchy, retrieving the original IMP from the next highest class each time, and calling that. By tracking the last class that we retrieved, we can emulate this. For each method, we set up a table that maps objects to the last class used for the call to the original IMP. By moving up the hierarchy from that class on each call, we can achieve the necessary behavior.

In the example above, the first call to ‘dealloc’ sees no table entry, so it calls B’s dealloc and puts B in the table. The next call sees B, calls A’s dealloc, and puts A in the table. The next call sees A and calls NSObject’s dealloc. This is all exactly as we want.

There’s one extra trick needed here. Imagine yet another class in the hierarchy, C:

1
    @interface C : B
2
    // does not override dealloc
3
    @end

This runs into a problem. The first call sees no table entry, calls C’s dealloc, and puts C in the table. However, since C doesn’t override dealloc, it’s actually just B’s dealloc. The next call sees the C in the table and calls… B’s dealloc again. This is not good.

The trick is to search the class hierarchy for the topmost class with the given method implementation. The TopClassImplementingMethod function searches up the class hierarchy from the given class, looking for the point where the IMP for a given selector changes, and then returns the last class from before that point:

1
    static Class TopClassImplementingMethod(Class start, SEL sel) {
2
        IMP imp = class_getMethodImplementation(start, sel);
3

4
        Class previous = start;
5
        Class cursor = class_getSuperclass(previous);
6
        while (cursor != Nil) {
7
            if (imp != class_getMethodImplementation(cursor, sel))
8
                break;
9
            previous = cursor;
10
            cursor = class_getSuperclass(cursor);
11
        }
12

13
        return previous;
14
    }

By calling this function before putting an entry in the table, this solves the problem. The first call will see no table entry, call C’s dealloc (which is really B’s dealloc), but then place B in the table instead of C. The next call goes to A, then NSObject as we need it to.

These tables would run into conflicts if the same method were invoked multiple times on different threads. However, by placing these tables in thread-local storage, that problem is eliminated.

ReleaseThe first thing the release swizzle does is fetch the thread-local struct, since it’s going to use the contents throughout the method:

1
    static void SwizzledReleaseIMP(PLObjectPtr self, SEL _cmd) {
2
        struct TLS *tls = GetTLS();

Next, we add self to the list of objects being released:

1
        pthread_mutex_lock(&gWeakMutex); {
2
            // Add this object to the list of releasing objects.
3
            CFBagAddValue(gReleasingObjects, self);
4
        } pthread_mutex_unlock(&gWeakMutex);

After that, we start on the fake super strategy. The first thing to do is see what the current table entry is:

1
        Class lastSent = (__bridge Class)CFDictionaryGetValue(tls->lastReleaseClassTable, self);

Then we pick a target class. If the table is empty, that’s just the class of self. If the table contains a class, then we start with that class’s superclass:

1
        Class targetClass = lastSent == Nil ? object_getClass(self) : class_getSuperclass(lastSent);

Then we use TopClassImplementingMethod to skip over classes that don’t override release, and store the result back into the table:

1
        targetClass = TopClassImplementingMethod(targetClass, releaseSELSwizzled);
2
        CFDictionarySetValue(tls->lastReleaseClassTable, self, (__bridge void *)targetClass);

With the target class in hand, the code can fetch the IMP for release on that target class and call it:

1
        void (*origIMP)(PLObjectPtr, SEL) = (__typeof__(origIMP))class_getMethodImplementation(targetClass, releaseSELSwizzled);
2
        origIMP(self, _cmd);

At this point, the superclass’s code has completed. If this call released the last reference to self, the object is now destroyed. The first thing to do is to clean up the class table so that the next call to release at this address (either the same object, if this release didn’t destroy it, or a new object allocated at the same location):

1
        CFDictionaryRemoveValue(tls->lastReleaseClassTable, self);

Finally, we reacquire the mutex to remove self from the list of releasing objects, calling pthread_cond_broadcast to wake up any threads that might be waiting on this object:

1
        pthread_mutex_lock(&gWeakMutex); {
2
            // We're no longer releasing.
3
            CFBagRemoveValue(gReleasingObjects, self);
4
            pthread_cond_broadcast(&gReleasingObjectsCond);
5
        } pthread_mutex_unlock(&gWeakMutex);
6
    }

DeallocThe swizzled dealloc implementation is largely similar. Like the swizzled release, it starts off by fetching the thread-local storage struct:

1
    static void SwizzledDeallocIMP(PLObjectPtr self, SEL _cmd) {
2
        struct TLS *tls = GetTLS();

Next, it grabs the global lock and clears all weak references to self by fetching the addresses from the global map and iterating over them:

1
        pthread_mutex_lock(&gWeakMutex); {
2
            // Clear all weak references and delete the addresses set.
3
            CFSetRef addresses = CFDictionaryGetValue(gObjectToAddressesMap, self);
4
            if (addresses != NULL)
5
                CFSetApplyFunction(addresses, ClearAddress, NULL);

Note that ClearAddress is just a simple function that essentially does *(void **)value = NULL to zero out every entry in the set. Now taht the set is clear, it’s no longer needed, so we remove it from the global map:

1
            CFDictionaryRemoveValue(gObjectToAddressesMap, self);

Finally, we notify anybody waiting on the list of releasing objects that it has changed. Technically, the list itself has not changed. However, anybody waiting on self will now find their weak reference contains nil, which isn’t in the set, so we still want to notify listeners to recheck:

1
            pthread_cond_broadcast(&gReleasingObjectsCond);
2
        } pthread_mutex_unlock(&gWeakMutex);

With that out of the way, dealloc uses the same procedure as release to call through to the original implementation:

1
        Class lastSent = (__bridge Class)CFDictionaryGetValue(tls->lastDeallocClassTable, self);
2
        Class targetClass = lastSent == Nil ? object_getClass(self) : class_getSuperclass(lastSent);
3
        targetClass = TopClassImplementingMethod(targetClass, deallocSELSwizzled);
4
        CFDictionarySetValue(tls->lastDeallocClassTable, self, (__bridge void *)targetClass);
5

6
        // Call through to the original implementation.
7
        void (*origIMP)(PLObjectPtr, SEL) = (__typeof__(origIMP))class_getMethodImplementation(targetClass, deallocSELSwizzled);
8
        origIMP(self, _cmd);

At this point, self is destroyed. All that remains is to clean up the entry in the class table for it, to leave it pristine for the next object to occupy this address:

1
        CFDictionaryRemoveValue(tls->lastDeallocClassTable, self);
2
    }

ConclusionThis is a tough problem to solve, but with careful thought and programming we’re able to make it all work. Swizzling release and dealloc allows safely zeroing out weak references to a target object. A table that tracks all objects currently in the middle of a release ensures that nobody can ever obtain a reference to an object that’s about to be destroyed. By tracking the class the swizzled method was sent to in an external table, we can safely swizzle these methods even when the swizzled method is called recursively.

That’s it for today. Come back next time for more wacky fun in the world of Cocoa programming. Friday Q&A is driven by reader suggestions, so in the meantime, if you have a topic that you’d like to see covered here, please send it in!