Собственно похожие темы уже освещались: http://forum.vingrad.ru/topic-278411.html
Напомню:
есть две программы: родительская и вызываемая (дочерняя)
- родительская создает некоторый канал, посредством pipe
- далее запускает fork
- в fork перенаправляет дескриптор stdout в пишущий конец, ранее созданной, трубы
- далее проиходит exec внешней программы
- в родительском по идее можно теперь читать из свободного конца трубы, то что пишет вызываемая программа
ЭТО ВСЕ РАБОТАЕТ за одним НО
Вот код


код приложения, которое мы запускаем

довольно примитивное приложение. таймеры сделаны для того, чтобы приложение не успело закрыться до того, как в родительском процессе не дошли до функции read.

Собственно вопрос: почему в канале родительского приложения данные от дочернего появляются только после завершения последнего? или же необходимо использовать сброс буфера fflush, тогда данные приходят в тот же момент?

если кто - то знает ответ, подскажите пожалуйста как можно решить этот момент, если конечно возможно...
неужели такая дикая буферизация?

надеюсь вопрос понятен, заранее благодарен за помощь

Это сообщение отредактировал(а) null56 - 15.4.2011, 13:25

при чем, проблема не в fork, из форка, если отправлять сообщения в новоиспеченный пайп, все доходит моментально... видимо под вопросом сам exec
системный вызов не этот отвечает за все семейство exec?
http://tomoyo.sourceforge.jp/cgi-bin/lxr/s...fs/exec.c#L1382

Ну для начала, стоит, наверное, обратить внимание на то, что в man pipe написано :



pipe_fd - МАССИВ из двух элементов

и проверять надобно pid

svlary, опечатка тут, в программе все верно
MAKCim, на что его проверять? да его номер соответствует запускаемой программе

для достоверности в правильности моего кода, есть glib функция, работающая аналогично, только использующая clone, эффект тот же
http://forum.vingrad.ru/forum/topic-327012.html

ЗЫ: поправил  pipe[2] в старте темы

Это сообщение отредактировал(а) null56 - 15.4.2011, 13:26

с stderr все нормально, работает как надо, видимо по умолчанию там стоит построчный вывод

Добавлено через 7 минут и 18 секунд
при чем попытка сделать stdout 

ни к чему не приводит, видимо execv сбрасывает назад

на дочерний/родительский процесс

MAKCim, в коде подобных ошибок нет... все проверяется... могу код предоставить, не только у меня такая вещь происходит, ведь с glib тоже подобный эффект с stdout. тут в другом проблема и она происходит после вызова exec*, судя по всему за счет кеширования данных ядром в буферах... при том в fork я могу сделать 
что - то типа

и перенаправление данных записанных в конец пайпа нормально без блокировки перенаправляется родительскому процессу, но после вызова exec видимо буферы опять выставляются в первоначальное состояние, после завершения процесса, ядро сбрасывает данные наконец в трубу.
с stderr ситуация прямопротивоположная. если я не ошибаюсь, там по умолчанию выставлено кеширование по линиям, поэтому данные приходят в другой конец пайпа без задержек
проверено на коде

данные из stderr доходят сразу после вызова, а вот stdout только после завершения программы... или, видимо, если переполнится буфер.
но на буфер, как было сказано выше я повлиять не могу. в общем система думаю примерна такая, пока нет времени разбираться с внутренностями

Добавлено @ 18:00
чтобы не гадали, упрощенный вариант кода (на синтаксические ошибки не обращайте внимания ибо копипастил с правкой на лету, дабы убрать лишнее)
если есть ошибки, буду рад услышать


Это сообщение отредактировал(а) null56 - 15.4.2011, 18:01

null56, 
вместо printf попробуй сделать write тут

или перед printf

Добавлено @ 18:24
MAKCim, да, знаю эту функцию, пробовал ее использовать перед exec, не катило.
согласен с тобой, но цель использовать не мое приложение, а чужое, не патчить же его...
но я уже забил на эту идею, ибо приложение умеет  кушать файл, я ему лучше его скормлю и проанализирую код возврата
если интересно: приложение nsupdate

Добавлено @ 18:25
в общем проблему, а она заключалась в вопросе "почему", думаю я разрешил для себя и видимо сделать на родительской стороне ничего поделать нельзя в юзермод

Добавлено через 10 минут и 18 секунд
спасибо большое всем за участие

Это сообщение отредактировал(а) null56 - 15.4.2011, 18:26

Странно все это... Именно сейчас я разрабатываю систему, в которой 5 процессов обмениваются информацией через 6 пайпов. И - никаких проблем! Все сообщения отправляются и доставляются практически мгновенно.  Единственная разница, которую я увидел : в моей программе обмен сообщениями осуществляется посредством write(...) -> read(...), а не посредством printf(..) -> read(...). Кстати говоря, мне кажется. что если уж на одном конце используется printf, то на другом конце надо использовать skanf(...);

  Кстати говоря, очень похоже, что :



просто-напросто висит, ожидая получения 255 байт. И ожидание завершается только в тот, момент, когда закрывается пайт - т.е. при  завершении приложения на "том" конце.  Посмотрите внимательно, в каком режиме открывается у Вас  pipe_fd[0]...

офф: Че-то у меня execv("/bin/ls", 0); не работает, а execl("/bin/ls", 0); работает

Добавлено через 12 минут и 44 секунды
После строчки надо добавить, потому что если exec не сработает, или дочерний процесс ничего не запишет, родительский процесс зависнет

это единственный close(), который тут нужен.

очевидно потому, что у execv второй аргумент char **. 

все верно, write не буферизуется, обратите внимание на то, что я написал: ПРОГРАММА, КОТОРАЯ ВЫВОДИТ - НЕ МОЯ!!! а так да, вы правы, так и нужно делать, чтобы получать немедленно  

Добавлено через 4 минуты и 50 секунд

я пытался передать и прочитать один байт, одно и тоже

Читаем man 2 write :



   В том смысле, что очень даже БУФЕРИЗУЕТСЯ!