pipe() для дерева процессов

касаемо pipe(), крайне рекомендуется покурить qmail-start.c (на этом базисе сделать 2-3 тестовых примера для себя) + в поисковик {named}pipe VS shared memory VS socket на предмет применимости

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

Посмотри на API пайпа и расскажи как ты это себе представляешь.

Смотрите, задача следующая:

Дерево процессов

Функциональные требования к программе (согласно варианту задания):
сразу после запуска должны порождаться несколько процессов, формируя определённое вариантом генеалогическое дерево процессов;

каждый из процессов должен вывести свой идентификатор и идентификатор родительского процесса; выполнить некоторые действия согласно варианту; вывести сообщение, что процесс с таким-то идентификатором и таким-то идентификатором родительского процесса завершает работу; отправку и получение любых данных каждым процессом необходимо сопровождать выводом сообщения, что процесс с таким-то идентификатором произвёл такие-то действия; приложение должно быть протестировано в различных вариантах запуска в терминале ОС Linux, в том числе в конвейерах с другими командами, с разными вариантами перенаправления потоков ввода-вывода. Все процессы должны выводить сообщения (см. функциональные требования), и, кроме того, производить дополнительные действия. Учтите, что передачу и получение информации каждым из процессов необходимо сопровождать выводом на экран информации типа «процесс такой-то передал/получил такую-то информацию таким-то образом (через конвейер, FIFO и т.д.)».

Каждый процесс, запустившись и сообщив об этом выводом строки в поток ошибки, должен отправить самому первому процессу сигнал SIGUSR1, а перед завершением работы сигнал SIGUSR2. При помощи этих сигналов первый процесс должен вести учет количества ваших процессов, функционирующих в данный момент в системе. По получении этих сигналов он должен вывести в поток ошибки сообщение с указанием этого количества.
Фиолетовый процесс выгружается последним. Прежде, чем завершиться, он должен создать новую директорию, в которую перенести все созданные в процессе работы файлы, а на их старом месте создать символические ссылки на эти файлы. Таким образом, после каждого из запусков должна оставаться новая директория с набором созданных файлов. Механизмы синхронизации и коммуникации между фиолетовым и остальными процессами выбрать по своему усмотрению.

Вариант 30. Жёлтый получает со стандартного потока ввода содержимое любого текстового файла и выводит на экран те его строки, которые начинаются с цифры, остальные строки передавая через FIFO зелёному. Тот заменяет в полученных строках X на Y и выводит результирующие строки на экран, а затем передаёт значение длины строки оранжевому при помощи семафоров (без дополнительных средств коммуникации). Оранжевый отображает на экран полученные значения и накопительную сумму и передаёт красному, используя общие файлы. Тот полученную информацию отображает на экране и сохраняет в файле.

_____________________________________________________________

Задача взята с другого форума, но там она дальше вопроса не ушла. Мой интерес исклчительно творческий - никакого «шкурного» интереса нет. Просто я как раз, для закрепления навыка программирования на Си, читаю книги по программированию под Linux. В принципе прочитал много, но там все как-то вроде понятно, а здесь такая роскошная задача )) Решил задачу решить, но... решить то я ее решу, но интересно было бы послушать мнение других. Например, использовать сокеты или нет, использовать может разделяемую память или файл и тп. Т.е., так сказать, архитектура интересует. Писать код не требуется (узкие моменты, если «в пня въеду, то тему отдельную создам лучше»). Операции со строками и тп не интересны (хотя интересно было бы написать модули работы со строками на С++ а вот можно потом к Си С++ модуль прилинковать?) Интересует коммуникация и видение как сия структура будет строиться и надо ли процессы отпочковывать exec() после fork() или достаточно fork(); Опыта мало, но представление общее в рамках Н.Иванов «Самоучитель программирования Linux» есть.

1. Как раскрутить процессы в указанное дерево

2. Какие коммуникации организовать между процессами? я предполагаю так(может я не прав):

enum Colors {blue, yellow, orange, ... };
pid_t CreateProcess(color);

Switch ( color ){
blue: CreateProcess(yellow, pid_t*); CreateProcess(yellow, pid_t*);
yellow: CreateProcess();
red
/// и так далее
} 

Дерево процессов

имхатеся задача сильно академическая, надо ближе к практике...

«очень, очень внимательно курим» qmail-start.c ...

- пытамемся сделать например, что-то вроде своего мини www - сервера (например стартовый www-start.c):

1.1 проверка запущен ли уже сервис через flock() в www-start.c

2.1 создание & закрытие pipe`(ов),

2.2 сброс привилегий - оттуда функции prot_uid, prot_gid

2.3 запуск демона www-db.c работающий через pipe() с www-send.c и через socket() c RDBMS

3.1 создание & закрытие pipe`(ов), создание сокета(:80) от рута

3.2 сброс привилегий - функции prot_uid, prot_gid

3.3 запуск www-send.c - непосредственно ядро сервиса, скажем диспетчер

3.3.1 простенький обработчик www запросов и работы со вспомогательными демонами

3.3.2 ядро этого демона будет функция select() - как никак тестовая аппликуха

3.3.3 часть кода ответственного за сетевой IO и двунаправленные списки можно взятьть из boa - www сервер

3.3.4 часть кода ответственную за работу cо вспомогательными демонами в www-send.c на pipe`ах, имо, лучше сделать на двунаправленных списках буферов с использованием TLV техники - это позволит добавить нек-рую расширяимость и гибкость

...

N. добавить демон для обхода (www-lspawn.c) пользовательских каталогов и пр.

N+1. опционально запуск вспомогательных демонов (на пример www-{css,cgi,php}.c ) и т.д.

- для начала все на ipc на pipe`ах, потом можно добавить прочее ipc по вкусам и задачам

...

P.S.:

- имхо, решение данной задачи позволит получить гораздо более ценный опыт

- сам написал ряд сетевых аппликух с использованием подобной архитектуры от DJB - жертв и разрушений нет

- смотрим посты с позывным fail на http://www.opennet.ru/openforum/vsluhforumID3/107139.html и в частности http://www.opennet.ru/openforum/vsluhforumID3/107139.html#30

- если что спрашиваем

Естественно, по pipe на ребро графа. Если и можно обойтись одним pipe, это будет геморрой на ровном месте.

Ещё есть очереди сообщений. Если рассматривать System V IPC (если его ещё не выпилии), то там у сообщение есть тип (long) и можно читать из очереди сообщения только заданного типа.

Ещё есть очереди сообщений

именованные каналы FIFO имеете в виду?

Нет. Совсем другой механизм: man svipc, msgget, msgrcv, msgsnd.

Нет. Совсем другой механизм: man svipc, msgget, msgrcv, msgsnd.

Хм, человеку с pipe`ми разобраться, а вы сразу тяжелые веса подбрасываете...))

Он сам задал такой вопрос:

А что у нас есть из IPC? Сокеты, каналы, именованные каналы, разделяемая память, разделяемый файл - на память вроде все.

Я просто дополнил список, совсем не обязательно, чтобы он прямо сейчас начинал изучать и кодить, просто для общего развития. А то сейчас не успеет, а лет через 10 отовсюду выпилят System V IPC :-)