Python: когда использовать pty.fork () по сравнению с os.fork ()
Я не уверен, использовать ли pty.fork() или os.fork() при порождении внешних фоновых процессов из моего приложения. (Такие как шахматные механизмы)
Я хочу, чтобы порожденные процессы умерли, если родитель уничтожается, как с мечущими икру приложениями в терминале.
Каковы взлеты и падения между этими двумя ветвлениями?
2 ответа
Дочерний процесс, созданный с помощью os.fork () , наследует stdin / stdout / stderr от родительского процесса, а дочерний процесс, созданный с помощью pty.fork ( ) подключен к новому псевдотерминалу. Позднее вам понадобится, когда вы напишете программу типа xterm: pty.fork () в родительском процессе возвращает дескриптор для терминала управления дочернего процесса,
к терминалу, может открыть ведомый конец
псевдотерминала, а затем быть
управляемый программой, которая
открыл главный конец. Все, что
написано на главном конце
предоставлен процессу на ведомом
конец, как если бы он был введен на
терминал. Например, написание
символ прерывания (обычно
Ctrl-C) на главное устройство
вызовет сигнал прерывания
(SIGINT) должен быть сгенерирован для
группа процессов переднего плана, которая
подключил к раб. Наоборот,
все, что написано в
ведомый конец псевдотерминала может
быть прочитанным процессом, который
подключен к главному концу.
В прошлом я всегда использовал для этого модуль subprocess . Он предоставляет хороший API для взаимодействия с подпроцессами.
Вы можете использовать call (* popenargs, ** kwargs) для блокировки их выполнения, и я полагаю, используя класс Popen может обрабатывать асинхронное выполнение.
Для получения дополнительной информации см. docs .
Что касается использования os.fork vs pty.fork , оба сильно зависят от платформы, и ни один из них не будет работать (или, по крайней мере, протестирован) с окнами. Модуль pty кажется более ограниченным из двух при чтении документации. Основное отличие - это аспект псевдотерминала. Поэтому, если вы не желаете строить свой код таким образом, чтобы можно было использовать модуль subprocess ,