Thread está siendo asesinado por el sistema operativo

Actualmente estoy progtwigndo una aplicación que extrae cuadros de un clip de película. Lo diseñé para que la extracción se realice en un hilo separado para evitar que la aplicación se congele. El process de extracción en sí está tomando muchos resources, pero funciona bien cuando se usa en el simulador. Sin embargo, hay problemas al crearlo para el iPad. Cuando realizo otra acción (le digo a mi reproductor AV que juegue mientras extraigo los cuadros), el hilo deja de funcionar inesperadamente y creo que lo matan.

Supongo que es porque estoy usando muchos resources, pero no del todo seguro.

Estas son mis preguntas: 1. ¿Cómo puedo saber si / por qué se interrumpe mi hilo? 2. Si realmente es por el exceso de procesamiento, ¿qué debo hacer? Realmente necesito esta acción para ser implementada.

Aquí hay algo de código que estoy usando: Para crear el hilo:

[NSThread detachNewThreadSelector:@selector(startReading) toTarget:self withObject:nil];

Publicaré cualquier información que necesites, muchas gracias!

Actualizar Estoy usando GCD ahora y llena los hilos para mí. Sin embargo, el sistema operativo aún mata los hilos.

Sé exactamente cuándo está sucediendo. cuando le digo a mi [AVplayer play]; mata el hilo

Este problema solo ocurre en el iPad real y no en el simulador.

Me parece que estás tratando de decodificar dos videoclips al mismo time. Debido a la naturaleza de deencoding basada en hardware del iPad, solo puede admitir un process de deencoding a la vez. Cuando juegas un nuevo elemento, el antiguo se cancelará. Esto explicaría por qué funciona en el simulador, pero no en el dispositivo.

En cuanto a una solución, puede cambiar a un decodificador de software puro como libav (GPL) o CoreAVC SDK (comercial). De esa forma, no interferirá con el decodificador HW para la reproducción.

Cuando algo funciona en el simulador y no funciona en un dispositivo, una explicación obvia es un problema de restricción de resources. Pero a veces el simulador no simula con precisión otros aspectos del funcionamiento del dispositivo. Entonces me pregunté si podría haber alguna otra interpretación de la situación. Se me ocurrió una posibilidad de que podría ser competencia para un activo limitado: acceso al Activo AV, lo que significa que cuando comienzas a jugarlo, ya no está disponible para procesarse (y, por alguna razón, un error en el simulador no muestra esta limitación).

En la Guía de progtwigción de la Fundación AV, en "Jugar activos", Apple declara:

Aunque en última instancia desea jugar un activo, no proporciona activos directamente a un object AVPlayer. En cambio, proporciona una instancia de AVPlayerItem. Un elemento de jugador gestiona el estado de presentación de un activo con el que está asociado. Un elemento de jugador contiene pistas de elemento de jugador, instancias de AVPlayerItemTrack, que corresponden a las pistas del elemento.

Esta abstracción significa que puedes jugar un activo determinado usando diferentes jugadores simultáneamente, pero que cada jugador los renderiza de diferentes maneras. Al usar las pistas del elemento, puede, por ejemplo, deshabilitar una pista en particular durante la reproducción (es posible que no desee reproducir el componente de sonido).

Entonces, me pregunté: ¿está utilizando AVPlayerItems para acceder a sus activos, que permitiría que ambas operaciones sucedan a la vez? Si es así, se descarta al less esa dirección específica. Pero si no, valdría la pena investigar para ver si soluciona el problema.

Podría estar agarrando a las pajas. Pero podría conducir a algún lado.

En la sección 'Configurar el tamaño de stack de un hilo' de la Guía de progtwigción de Threading de Apple, la página 27 dice:

En iOS y Mac OS X v10.5 y posteriores, asigne e inicialice un object NSThread (no use detachNewThreadSelector: toTarget: withObject: method)

Aunque en la página 22 dice detachNewThreadSelector es una de las forms de crear hilos usando NSThread.

Y da este ejemplo en la página 23 de cómo comenzar su hilo:

 NSThread* myThread = [[NSThread alloc] initWithTarget:self selector:@selector(myThreadMainMethod:) object:nil]; [myThread start]; 

De acuerdo con la guía que creará un hilo suelto en tu aplicación. Intenta crear tu hilo de esta manera y mira si el sistema operativo deja de matar tu hilo.

Para reference aquí es el enlace a la guía

http://developer.apple.com/library/ios/iPad/#documentation/Cocoa/Conceptual/Multithreading/CreatingThreads/CreatingThreads.html#//apple_ref/doc/uid/10000057i-CH15-SW2

También menciona en la página 29 que si su aplicación usa el model de memory administrada, lo que parece que usted es, crear una agrupación de autorelease en su rutina de input de subprocess debería ser lo primero que hace y destruir de manera similar lo último que hace su subprocess. No estoy seguro de no tener esto causaría la eliminación de tu hilo, pero verifica que hagas esto.

Tener un bloque try / catch en su rutina de input de subprocesss puede no resolver el problema de matar, pero evitará que su aplicación salga si se produce un error en su subprocess.

Olvidé mencionar este otro consejo de layout que puede ayudarte con las limitaciones de resources, como mencionó Duncan. De acuerdo con la página 18 de la guía:

Evitar estructuras de datos compartidos

La forma más simple y fácil de evitar conflictos de resources relacionados con subprocesss es otorgar a cada subprocess de su progtwig su propia copy de los datos que necesite. El código paralelo funciona mejor cuando minimiza la comunicación y la contención de resources entre sus hilos.

Lo cual, creo que puedes hacer eso en tu aplicación. Además de hacer lo que Duncan mencionó "no proporcione activos directamente a un object AVPlayer sino que proporcione una instancia de AVPlayerItem", hágalo creando instancias separadas para cada uno de sus hilos, una instancia de AVPlayerItem para el hilo de reproducción y una instancia de AVPlayerItem para el hilo de extracción.