Zstd: ZSTD en iOS: ¿se requiere alineación a 32 bits?

Creado en 26 jun. 2018 · 3Comentarios · Fuente: facebook/zstd

Hola

En primer lugar, ¡gracias por ZSTD!

He estado persiguiendo un bloqueo en mi aplicación de iOS que aprovecha ZSTD 1.3.4, y ocasionalmente obtengo un bloqueo en MEM_write32 al comprimir con un contexto sin diccionario:

    NSData* metadata = (snip)
    const size_t expectedCompressionSize = ZSTD_compressBound(metadata.length);

    UInt8* compressionBuffer = malloc(expectedCompressionSize);

    size_t const compressedSize = ZSTD_compressCCtx(compressionContext, compressionBuffer, expectedCompressionSize, metadata.bytes, (size_t) metadata.length, 1);

    // Hit error on compression use ZSTD_getErrorName for error reporting eventually.
    if(ZSTD_isError(compressedSize))
    {
        free(compressionBuffer);
        return nil;
    }

    NSData* zstdCompressedData = [[NSData alloc] initWithBytesNoCopy:compressionBuffer length:compressedSize freeWhenDone:YES];

¿Existe algún requisito de alineación o matices para la implementación en iOS / Arm? He notado algunos align = 32 en los archivos make, pero no vi nada específico en los documentos para iOS. ¿Hay alineaciones de clang específicas?

¿Hay algún matiz con el uso de ZSTD_compressCCtx en una cola de envío en serie (no un solo hilo, sino una invocación serializada garantizada de una instancia de contexto que se puede usar en unos pocos hilos del sistema pero nunca concurrente)?

¡Gracias por cualquier información!

question

Fuente

vade

👍1

Todos 3 comentarios

Se supone que MEM_write32() funciona con cualquier objetivo, incluidos aquellos que requieren alineaciones estrictas.
Puede haber algunas sutilezas con algunos dispositivos de bajo consumo poco comunes, pero para los de iOS, no espero ningún problema. Además, la mayoría de los dispositivos iOS modernos utilizan un derivado ARM de 64 bits, que puede leer / escribir en direcciones no alineadas, como una CPU x86 de escritorio.
Así que me sorprendería mucho que la alineación fuera un problema en este caso.

Otra posibilidad es que MEM_write32() escriba en una dirección no autorizada.
No está claro por qué sucedería.
Se supone que ZSTD_compressCCtx() es seguro frente a los desbordamientos de búfer.

También mencionas trabajar en un entorno de subprocesos múltiples.
Un contexto determinado solo debe ser utilizado por un hilo a la vez.
Puede cambiar de hilo. Pero lo realmente importante es que no deben usar 2 subprocesos al mismo tiempo.
Entiendo que se supone que su implementación se encargará de esta condición.
Pero te invitaría a mirar de nuevo.
A veces, puede ser bastante difícil garantizar tal condición, dependiendo de los detalles de implementación.

Recomendaría ejecutar su aplicación con un desinfectante de hilos. Debería poder marcar cualquier uso indebido, si lo hubiera.

Cyan4973 en 26 jun. 2018

👍1

Gracias @ Cyan4973 por las aclaraciones para la alineación y el enhebrado WRT para acceder a un contexto de compresión ZSTD. Creo que sigo la regla que mencionas (es seguro para el acceso estrictamente en serie a través de varios subprocesos, pero no es seguro para el acceso concurrente). También sé lo difícil que puede ser realmente garantizar que ese sea el caso :) dispatch_async a través de Apples libDispatch / Grand Central Dispatch debería permitir una adherencia estricta, pero tal vez no soy tan hábil como me gustaría pensar :)

Siéntase libre de cerrar este problema ya que es una pregunta en lugar de un error, y lo ha aclarado. Si encuentro algún comportamiento de bloqueo específico que pueda aislar o que genere una pregunta adicional, enviaré un nuevo "error".

Aprecio la completa respuesta. ¡Gracias!

vade en 26 jun. 2018

👍1

Tu corazonada está totalmente muerta y enhebrar es complicado. Gracias por la patada en el trasero para comprobarlo tres veces.

vade en 27 jun. 2018

¿Fue útil esta página

0 / 5 - 0 calificaciones