Programa de Python que usa os.pipe y os.fork() problema

Question

Recientemente he necesitado escribir un script que realiza un os.fork() para dividirlo en dos procesos. El proceso secundario se convierte en un proceso de servidor y transfiere los datos al proceso principal utilizando un conducto creado con os.pipe(). El hijo cierra el extremo 'r' de la tubería y el padre cierra el extremo 'w' de la tubería, como de costumbre. Convierto los retornos de pipe() en objetos de archivo con os.fdopen.

El problema que estoy teniendo es esto: el proceso se bifurca con éxito, y el niño se convierte en un servidor. Todo funciona muy bien y el niño escribe diligentemente los datos en el extremo abierto de la tubería 'w'. Lamentablemente, el extremo inicial de la tubería hace dos cosas extrañas:
A) Bloquea en la operación read() en el extremo 'r' de la tubería.
En segundo lugar, no puede leer los datos que se colocaron en el conducto a menos que el extremo 'w' esté completamente cerrado.

Inmediatamente pensé que el problema era el almacenamiento en búfer y agregué pipe.flush() llamadas, pero estas no ayudaron.

¿Alguien puede arrojar algo de luz sobre por qué los datos no aparecen hasta que el final de la escritura está completamente cerrado? ¿Y existe una estrategia para hacer que la llamada read() no bloquee?

Este es mi primer programa de Python que bifurcó o usó tuberías, así que perdónenme si cometí un simple error.

Answer 1

¿Está utilizando read() sin especificar un tamaño o tratando el conducto como un iterador (for line in f)?Si es así, esa es probablemente la fuente de su problema: read() se define para leer hasta el final del archivo antes de regresar, en lugar de solo leer lo que está disponible para leer. Eso significará que bloqueará hasta que el niño llame close().

En el código de ejemplo vinculado a, esto está bien: el elemento principal actúa de forma bloqueante y solo usa el elemento secundario para fines de aislamiento. Si desea continuar, utilice E/S no bloqueante como en el código que publicó (pero prepárese para tratar la mitad de los datos completos) o lea en fragmentos (por ejemplo, r.read (tamaño) o r.readline()) que bloqueará solo hasta que se haya leído un tamaño/línea específico. (aún necesitará llamar a color en el niño)

Parece que tratar el conducto ya que un iterador también está usando otro buffer, para "for line in r:" puede que no le proporcione lo que usted necesita si necesita cada línea para ser consumido inmediatamente Puede ser posible desactivar esto, pero simplemente especificar 0 para el tamaño del búfer en fdopen no parece suficiente.

Heres un código de ejemplo que debería funcionar:

import os, sys, time 

r,w=os.pipe() 
r,w=os.fdopen(r,'r',0), os.fdopen(w,'w',0) 

pid = os.fork() 
if pid:   # Parent 
    w.close() 
    while 1: 
     data=r.readline() 
     if not data: break 
     print "parent read: " + data.strip() 
else:   # Child 
    r.close() 
    for i in range(10): 
     print >>w, "line %s" % i 
     w.flush() 
     time.sleep(1) 

Answer 2

La parte "principal" frente a "secundaria" de fork en una aplicación de Python es tonta. Es un legado de los días de Unix de 16 bits. Es una afectación de un día en que fork/exec y exec eran cosas importantes para sacar el máximo provecho de un pequeño y pequeño procesador.

Divida su código de Python en dos partes separadas: principal e hijo.

La parte principal debe usar subprocess para ejecutar la parte secundaria.

Un tenedor y un ejecutivo pueden aparecer en algún lugar, pero no es necesario que se preocupe.

Answer 3

Here's un código de ejemplo para hacer esto.

Answer 4

Usando

fcntl.fcntl(readPipe, fcntl.F_SETFL, os.O_NONBLOCK)

Antes de invocar la lectura() resuelto ambos problemas. La llamada a la función de lectura() ya no está bloqueando y los datos aparecen después de solo una descarga() en el extremo de escritura.

Answer 5

Veo que ha resuelto el problema de bloqueo de E/S y almacenamiento en búfer.

Una nota si decide probar un enfoque diferente: subproceso es el equivalente/un reemplazo para la expresión fork/exec. Parece que no es eso lo que estás haciendo: solo tienes un tenedor (no un ejecutivo) e intercambias datos entre los dos procesos; en este caso, el módulo multiprocessing (en Python 2.6+) sería una mejor opción.