Кто-то может объяснить буферную мертвую блокировку канала?
Документация Python к состояниям Popen:
Предупреждение Использования связывается (), а не .stdin.write, .stdout.read или .stderr.read для предотвращения мертвых блокировок из-за любого из других заполняющихся буферов канала ОС и блокирование дочернего процесса.
Теперь, я пытаюсь выяснить, как эта мертвая блокировка может произойти и почему.
Моя умственная модель: subproccess производит что-то для stdout/err, который буферизуется и после того, как буфер заполнен, он сбрасывается к stdout/err subproccess, который является, отправляют через канал к родительскому процессу.
Из того, что документация указывает, канал имеет свой собственный буфер и когда это заполнено, или подпроцесс завершается, это сбрасывается к к родительскому процессу.
Так или иначе (с буфером канала или не), я не совсем уверен, как мертвая блокировка может произойти. Только вещью, о которой я могу думать, являются некоторые "глобальные" буферные процессы канала ОС, будет бороться за, который звучит странным. Другой - это, больше процессов совместно использует тот же канал, которого не должно происходить на своем собственном.
Кто-то может объяснить это?
2 ответа
Осторожно, здесь есть небольшая ошибка.
Моя ментальная модель: подпроцесс производит что-то для stdout / err, которое буферизуется, и после заполнения буфера сбрасывается в stdout / err из {{1} } подпроцесс, который отправляется через канал родительскому процессу.
Буфер используется совместно родительским и дочерним процессами.
Подпроцесс производит что-то в stdout, который является тем же буфером, из которого, как предполагается, будет читать родительский процесс.
Когда буфер заполнен, запись останавливается до тех пор, пока буфер не будет опустошен. Flush ничего не значит для канала, поскольку два процесса используют один и тот же буфер.
Сброс на диск означает, что драйвер устройства должен передать байты устройству. Очистка сокета означает, что TCP / IP перестает ждать накопления буфера и отправки материала. Сброс на консоль означает прекращение ожидания новой строки и передачу байтов через драйвер устройства на устройство.
Тупиковая ситуация может возникнуть, когда оба буфера (stdin и stdout) заполнены: ваша программа ожидает записи дополнительных данных во внешнюю программу, а внешняя программа ожидает, что вы сначала прочитаете из его выходного буфера.
Эту проблему можно решить, используя неблокирующий ввод-вывод и правильно расставляя приоритеты для буферов. Вы можете попробовать заставить его работать самостоятельно, но communication () сделает это за вас.