Программа Python, использующая проблему os.pipe и os.fork()

Вы используете read() без указания размера или рассматриваете канал как итератор (for line in f)? Если это так, то это, вероятно, источник вашей проблемы - read() определен для чтения до конца файла перед возвратом, а не просто для чтения того, что доступно для чтения. Это будет означать, что он будет заблокирован до тех пор, пока ребенок не вызовет close().

В приведенном примере кода это нормально — родитель действует блокирующим образом и просто использует дочерний элемент в целях изоляции. Если вы хотите продолжить, то либо используйте неблокирующий ввод-вывод, как в коде, который вы разместили (но будьте готовы иметь дело с полуполными данными), либо читайте кусками (например, r.read(size) или r.readline() ), который будет блокироваться только до тех пор, пока не будет прочитан определенный размер/строка. (вам все равно нужно вызвать флеш для ребенка)

Похоже, что обработка канала как итератора также использует дополнительный буфер, поскольку «for line in r:» может не дать вам того, что вы хотите, если вам нужно, чтобы каждая строка была немедленно использована. Возможно, это можно отключить, но просто указать 0 для размера буфера в fdopen кажется недостаточным.

Вот пример кода, который должен работать:

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)

С использованием

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

Перед вызовом read() решил обе проблемы. Вызов read() больше не блокируется, и данные появляются после сброса() в конце записи.

Я вижу, вы решили проблему блокировки ввода-вывода и буферизации.

Примечание, если вы решите попробовать другой подход: subprocess является эквивалентом/заменой идиомы fork/exec. Кажется, что это не то, что вы делаете: у вас есть только вилка (не exec) и обмен данными между двумя процессами - в этом случае multiprocessing (в Python 2.6+) подойдет лучше.

«Родительская» и «дочерняя» часть fork в приложении Python глупы. Это наследие 16-битных дней Unix. Это притворство того дня, когда fork/exec и exec были важными вещами, чтобы максимально использовать крошечный процессор.

Разбейте свой код Python на две отдельные части: родительскую и дочернюю.

Родительская часть должна использовать подпроцесс для запуска дочерней части.

Где-то там может произойти fork и exec, но вам не нужно об этом заботиться.