Давай на ты, а то это вы/ты выглядит немного странно.

Андрей Светлов
Ну что же вы? Пытались рассуждать как совсем взрослый, а на такой ошибочке споткнулись…

Кто вам сказал, что grep работает именно построчно? Закроете stdin - все будет хорошо. Получите ухудшенную версию .communicate

Угу, а теперь запусти grep “” и вводи по сторочке с клавиатуры.
Все это проверялось с моей собственной прогой, которая гарантированно работает построчно.

Андрей Светлов
В качестве разминки попробуйте представить систему, в которой чтение из stdin должно чередоваться с записью в stdout.
У нее куча логических противоречий. Написать для конкретного случая можно, в общем виде - не решается.

Отлично, но как ты представляешь сабж, если через него надо програть данные на x0 Mb? Или такой случай невозможен?

Хорошо. А ты grep как запускал? Просто grep pattern?
Смотрим исходники. Ооо. Для не-tty терминала (наш случай, запуск из subprocess.Popen) работает чуть иначе, чем для консольки.

Если нужно обработать много - нет проблем.
Для grep случай простой - запись и чтение идут независимо. Действительно, можно прикрутить select и нормально все обрабатывать.

Если захотим порулить gdb (а все отладчики в linux как раз gdb и запускают, никто не пытается делать работу самому) - ситуация немного сложнее.
Особенность в том, что после write в stdin нужно как-то узнать, сколько байт следует вычитать в ответе из stdout.

Специально для этого в gdb разработали serial protocol - c пакетами, контрольными суммами и так далее. С оговоренным протоколом все сразу стало гораздо проще, неопределенность исчезла.

Поэтому я и написал, что в общем виде не решается. И communicate поэтому такой простой. Это как с сокетами. Пока не изобретешь формат общения - что-то толковое сделать нелегко.

Ну у меня задача проще - на каждую строчку ввода должна быть строчка вывода, причем связывать их друг с другом может быть даже и не надо.

С селектом гиморноватей, конечно. Примеров я не нашел.

Андрей Светлов
Для не-tty терминала (наш случай, запуск из subprocess.Popen) работает чуть иначе, чем для консольки.

Суть остается та же - никто не ждет конца потока, результат выдается по мере поступления ввода.

Для select все просто. Но на Windows как раз select использовать нельзя - он не работает с PIPE.
В результате, кажется, приходится плясать с бубном вокруг WaitForMultipleObject.
Написать код не могу - мне его проверять не на чем.

Андрей Светлов
Написать код не могу - мне его проверять не на чем.

Это такой тонко замаскированый вендекапец++?

Можно еще сделать 2 потока, в одном чтение, в другом запись. Короче, те же грабли, что и с сокетами, вот уж не ожидал, что здесь их встречу. Мдя :(

Может быть еще неблокирующие хэндлы?

У меня Убунта. Виндовую виртуалку крепко сломал пару недель назад. Восстанавливать пока не было особой нужды.

Неблокирующие хэндлы? Отчего бы и нет, если тебе так удобней.

Как ты правильно заметил, полноценное общение с запущенным процессом очень похоже на сокеты. И да, грабли те же.

asilyator, смотри http://www.python.org/dev/peps/pep-3145/
Специально под тебя делано.

Вроде greenlet/stackless здесь поможет.
А syncless ещё и патч для subprocess имеет.

..bw