RetainCount == MALO

retainCount Es tabú, poco fiable, impredecible y, en general, no debe utilizarse. No lo uso en ninguna parte de mi código, pero lo he visto en una clase que uso de una manera interesante.

Tengo una clase que ejecuta un hilo que se ejecuta indefinidamente hasta que se cancela el hilo. El problema es que el hilo aumenta la cuenta de retención del propietario, en mi caso, la clase que lo creó. Por lo tanto, incluso si he terminado de usar esa clase, esa instancia seguirá en suspenso a menos que quien esté administrando mi clase también tenga la inteligencia de saber cómo cerrar el hilo. Esa es una solución, pero esto es lo que encontré en el código.

<code>- (oneway void)release
{
    // This override allows allows this object to be dealloced 
    // by shutting down the thread when the thread holds the last reference.
    // Otherwise, the object will never be dealloc'd
    if (self.retainCount == 2)
    {
        [self quitDispatchThread];
    }

    [super release];
}
</code>

Esta es una solución inteligente, pero no estoy seguro de qué pensar. Anula la liberación en la clase y verifica si el recuento de retención es 2. En otras palabras,verifica si el hilo es lo único que mantiene vivo mi objeto (ya que el recuento de retenciones está a punto de disminuirse de 2 a 1) y, si lo está, termina el hilo (quitDispatchThread se bloqueará hasta que se termine el hilo).

Asi que...

¿Puedes confiar en retainCount para ver si es uno?

Usualmente la gente dice mantenerse alejado deretainCount porque no sabes si hay algunos autoreleases allí. Sin embargo, si el reténCuple es uno, entonces sé que solo el hilo lo mantiene vivo y no tengo que preocuparme de que el reténcontador esté apagado debido a algunas autoreleases, etc.

¿Qué hay de malo con este código?

Estaba a punto de eliminarlo, pero en realidad parece tener sentido. Otros objetos no tienen que ser conscientes de que mi clase está ejecutando un hilo. Otros objetos pueden con seguridadretain yrelease o inclusoautorelease el objeto que posee el hilo sin tener que preocuparse por cerrar el hilo porque se cuida a sí mismo.

Este código en realidad se siente limpio, lo que me sorprende.

Edit :: NSThread está reteniendo mi objeto

La cuenta de retención de mi objeto se incrementa por el hecho de que estoy usando NSThread. Mi objeto es eltarget y elselector es el método en el que se ejecuta el hilo.

initWithTarget: selector: objeto:

Devuelve un objeto NSThread inicializado con los argumentos dados.

(id) initWithTarget: (id) selector de destino: (SEL) objeto selector: (id) argumento

Parámetros

objetivo

El objeto al que se envía el mensaje especificado por el selector.

selector

El selector para el mensaje a enviar a destino. Este selector debe tomar solo un argumento y no debe tener un valor de retorno.

argumento

El único argumento pasado al objetivo. Puede ser nulo.

Valor de retorno

Un objeto NSThread inicializado con los argumentos dados.

Discusión

Para las aplicaciones no recolectadas en la basura, el selector de método es responsable de configurar un grupo de liberación automática para el subproceso recién separado y liberar ese grupo antes de que salga. Las aplicaciones recolectadas en la basura no necesitan crear un grupo de autorelease.

Los objetos destino y el argumento se conservan durante la ejecución del subproceso separado. Se liberan cuando el hilo finalmente sale.