Pregunta

sizeWithFont estrelló en multi-hilo, esta es la información de depuración:

1 0x00a0df8e in icu::RuleBasedBreakIterator::handleNext
2 0x00a0daff in icu::RuleBasedBreakIterator::next
3 0x00a0d174 in icu::RuleBasedBreakIterator::following
4 0x35879719 in WebCore::nextBreakablePosition
5 0x3587842a in -[NSString(WebStringDrawing) _web_drawInRect:withFont:ellipsis:alignment:lineSpacing:includeEmoji:measureOnly:]
6 0x35877da3 in -[NSString(WebStringDrawing) _web_sizeInRect:withFont:ellipsis:lineSpacing:]
7 0x3090d238 in -[NSString(UIStringDrawing) sizeWithFont:constrainedToSize:lineBreakMode:lineSpacing:]
8 0x3090cee3 in -[NSString(UIStringDrawing) sizeWithFont:constrainedToSize:lineBreakMode:]

ahora a resolver el error mediante el uso de un objeto NSLock, antes de utilizar esta función Voy a bloquear este objeto, y después de que se desbloquee

pero yo creo que debe haber una solución más mejor!

y me encontré con este error sólo aparece cuando el objeto NSString para esta función en ambos dos hilos son múltiples líneas de texto

¿Fue útil?

Solución

No Como regla general, usted debe llamar a los métodos UIKit [1] a partir de un hilo separado. No importa si usted está tomando cerraduras, esto es un no-arrancador.

Cuando se está utilizando aplicaciones de subprocesos múltiples, es necesario asegurarse de que cualquier código que toca cualquier UIKit objetos se ejecuta en el hilo principal. Esto se logra mediante el uso de la performSelectorOnMainThread: withObject: waitUntilDone: método que invoca el selector dado en el hilo principal:

http://developer.apple.com/iphone/library/documentation/cocoa/reference/foundation/Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ / INSTM / NSObject / performSelectorOnMainThread: withObject: waitUntilDone :

O en MonoTouch: foo.InvokeOnMainThread (delegado {your_code_here});

[1] Con iOS 4.0 la regla es relajado para un puñado de API.

Otros consejos

  • El formato, por favor.

  • "Solución" un problema multi-roscado mediante la colocación de cerraduras al azar alrededor de los objetos no es la respuesta correcta. Jamas. Multi-threading requiere un diseño sistémico de su aplicación.

  • Si un bloqueo hace "solución" al problema, que muestra lo que ha bloqueado y cómo es crítico para evaluar la situación.

  • Algunas más síntomas serían útiles. Código, en particular. Código en sus preguntas es muy útil.

Dada la falta de pruebas, apostaría a que su están mutando una cadena en un hilo al intentar agarrar el tamaño en otra. O el objeto que está siendo liberado en un hilo sin dejar de utilizar de otra. O está manipulando un objeto desde un subproceso secundario que no es hilo de seguridad.

Creo performSelectorOnMainThread: withObject: waitUntilDone: es correcto,

Antes, yo uso una operación para calcular el tamaño del texto, Y el uso waitUntilAllOperationsAreFinished en el hilo principal para esperar el regreso de la operación,
Pero si también utilizo performSelectorOnMainThread: withObject: waitUntilDone en la operación, y establecer el parámetro a waitUntilDone Sí (porque necesito el resultado)
El hilo principal se stucked

Así que ahora me quito waitUntilAllOperationsAreFinished, y utilizar un objeto asíncrono para asegurar la operación no se iniciará hasta que el anterior se detuvo

                    [md removeAllObjects];
                    [md setObject:subString forKey:@"text"];
                    [md setObject:[NSNumber numberWithInt:view_w ] forKey:@"width"];
                    [md setObject:[NSNumber numberWithInt:height_left + font_h ] forKey:@"height"];
                    [self  performSelectorOnMainThread:
                     @selector(calculateTextRegion:)
                                            withObject:md
                                         waitUntilDone:YES];
                    CGSize stringSize = textRegion;
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top