Che cosa è un "non-debole di riferimento azzeramento"

Question

Nel OS X v10.11 beta release notes, trovo il seguente:

NSNotificationCenter e NSDistributedNotificationCenter inviare più notifiche agli osservatori registrati che possono essere deallocata. Se l'osservatore è in grado di essere memorizzato come riferimento di azzeramento debole, la memoria sottostante memorizza l'osservatore come riferimento debole di azzeramento. In alternativa, se l'oggetto non può essere memorizzato debolmente (poiché ha un meccanismo di conservazione/rilascio personalizzato che impedisce al runtime di essere in grado di archiviare debolmente l'oggetto) l'oggetto viene memorizzato come riferimento di azzeramento non debole. Ciò significa che agli osservatori non è richiesto di annullare la registrazione nel loro metodo di deallocazione. [emphasis mine]

Questo non ha senso per me. Se si tratta di un riferimento non debole, allora non sarebbe un riferimento forte? Quindi NSNotificationCenter sarebbe ancora un proprietario, quindi l'oggetto non avrebbe deallocato (fino alla registrazione non registrata manualmente), quindi in questo contesto è assurdo affermare che si tratta di "azzeramento".

Se si riferisce a una sorta di riferimento __unsafe_unretained, la domanda è ... in che modo NSNotificationCenter potrebbe evitare di inviare messaggi a uno zombie?

Answer 1

La risposta per questo si trova nel runtime oggettivo-c e in che modo le variabili __weak funzionano effettivamente. Per spiegare, diamo un'occhiata un po 'alla objc_weak.mm:

id 
weak_read_no_lock(weak_table_t *weak_table, id *referrer_id) 
{ 
    ... 

    if (! referent->ISA()->hasCustomRR()) { 
     if (! referent->rootTryRetain()) { 
      return nil; 
     } 
    } 
    else { 
     BOOL (*tryRetain)(objc_object *, SEL) = (BOOL(*)(objc_object *, SEL)) 
      object_getMethodImplementation((id)referent, 
              SEL_retainWeakReference); 
     if ((IMP)tryRetain == _objc_msgForward) { 
      return nil; 
     } 
     if (! (*tryRetain)(referent, SEL_retainWeakReference)) { 
      return nil; 
     } 
    } 

    return (id)referent; 
} 

Come si può vedere, quando personalizzati -retain e -release metodi sono utilizzati da un oggetto, non è garantito che essi supportano riferimenti deboli a tutti (si noti anche che si può usare un oggetto completamente diverso per i riferimenti deboli di un oggetto, anche se questo è un argomento per un'altra volta).

Questo perché i riferimenti deboli vengono puliti da objc_destructInstance, che chiama objc_clearDeallocating, che chiama weak_clear_no_lock.

Ora, non è necessario che objc_destructInstance venga chiamato da implementazioni di oggetti personalizzati, sebbene la maggior parte degli oggetti lo chiamerà.

Così, il tempo di esecuzione consente di implementare il metodo -allowsWeakReference (e retainWeakReference) per disabilitare i riferimenti deboli per l'oggetto, nel qual caso è più probabile zero'd da swizzling -dealloc sull'oggetto. Naturalmente, si tratta di tutti i dettagli di implementazione, quindi NSNotificationCenter potrebbe avere il proprio modo innovativo di fare le cose, ma questa è la mia ipotesi migliore senza tentare di disassemblare NSNotificationCenter.

Answer 2

Dichiarare una proprietà come forte rende quella proprietà un riferimento forte. La dichiarazione come debole utilizza un riferimento debole di azzeramento.Il unsafe_unretained modificatore utilizza un riferimento debole non azzeramento

Brevemente: non-weak zeroing reference == unsafe_unretained refernce

Riferimento:

https://mikeash.com/pyblog/friday-qa-2011-09-30-automatic-reference-counting.html http://www.jessesquires.com/UIKit-changes-in-iOS-9/