Python: es os.read()/os.write() en un os.pipe() threadsafe?

Question

considerar:

pipe_read, pipe_write = os.pipe() 

Ahora, me gustaría saber dos cosas:

(1) Tengo dos hilos. Si garantizo que solo uno está leyendo os.read(pipe_read,n) y el otro solo está escribiendo os.write(pipe_write), ¿tendré algún problema, incluso si los dos hilos lo hacen simultáneamente? ¿Recibiré todos los datos escritos en el orden correcto? ¿Qué pasa si lo hacen simultáneamente? ¿Es posible que una sola escritura se lee en pedazos, como ?:

Thread 1: os.write(pipe_write, '1234567') 
Thread 2: os.read(pipe_read,big_number) --> '123' 
Thread 2: os.read(pipe_read,big_number) --> '4567' 

O - de nuevo, tenga en cuenta la simultaneidad - tendrá un solo os.write(some_string) siempre devolverá en su totalidad por un único os.read(pipe_read, very_big_number)?

(2) Considerar más de un hilo escrito al final pipe_write de la tubería usando logging.handlers.FileHandler() - He leído que el módulo de registro es multi-hilo. ¿Esto significa que puedo hacer esto sin perder datos? Creo que no podré controlar el orden de los datos en la tubería; pero esto no es un requisito. Requisitos:

• todos los datos escritos por algunos hilos en el extremo de escritura deben salido al final leer
• una cadena escrita por un solo logger.info(), logger.error(), ... tiene que permanecer en una sola pieza.

¿Se cumplen estos requisitos?

gracias de antemano,

Jan-Philip Gehrcke

Answer 1

os.read y os.write en los dos FDS regresaron de os.pipe es multi-hilo, pero se parece a exigir más que eso. Sub (1), sí, no hay garantía de "atomicidad" para las lecturas o escrituras de sinle: el escenario que representa (una sola escritura corta termina produciendo dos lecturas) es completamente posible. (En general, os.whatever es una envoltura delgada de la funcionalidad del sistema operativo, y le corresponde al sistema operativo asegurar o no garantizar el tipo de funcionalidad que necesita, en este caso, el estándar de Posix no requiere el sistema operativo para asegurar este tipo de "atomicidad"). Tiene la garantía de obtener todos los datos que se escribieron, y en el orden correcto, pero eso es todo. Una sola lectura de un pedazo grande de datos podría estancar una vez que se llena el buffer OS-suministrado y sólo procederá una vez que algún otro flujo ha leído algunos de los datos iniciales (cuidado con los puntos muertos, por supuesto!), Etc, etc.

Sub (2), sí, el módulo de registro es threadsafe Y "atómico" en los datos producidos por una sola llamada a logging.info, logging.warn, logging.error, etc., "se mantiene en una sola pieza" en términos de llamadas al subyacente manejador (sin embargo, si ese manejador a su vez utiliza medios no atómicos como os.write, aún puede, por ejemplo, bloquearse en el kernel hasta que el búfer subyacente se desatasque, etc., etc., como se indicó anteriormente).