Как dipcd создает процессы

Потоки позволяют ``разветвить'' задачи для их параллельного выполнения и предоставить совместный доступ к общему адресному пространству. К сожалению, иногда потоки могут не поддерживаться. Это означает, что если в программе желательно выполнять множество действий в одно и то же время, то в ней нужно использовать системный вызов fork(), предполагая, что общего адресного пространства нет, и заботиться о средствах связи между процессами.

Другим способом разрешения данной проблемы является реализация процессом его предназначения настолько быстро, насколько это возможно - при этом способе процессы отрабатывают один за другим; dipcd использует оба метода: некоторые из процессов раздваиваются, когда ожидается их активность в течение длительного времени (например, referee раздваивается), а некоторые процессы выполняются последовательно, с надеждой, что запросы на обслуживание не будут подавлять их (shm_man работает таким образом).

На рис. 1 показаны взаимоотношения между процессами dipcd и последбвательность их создания.

Рис. 1. Взаимоотношения процессов DIPC

1. Программа dipcd может исполняться пользователем (или автоматически - из загрузочного скрипта). Процесс back_end получает контроль.
2. Процесс front_end раздваивается процессом back_end.
3. back_end раздваивает процесс referee, если данный компьютер также должен содержать referee.
4. Процесс back_end раздваивает employer, когда он ``открывает'' работу DIPC внутри ядра.
5. Процесс front_end раздваивает worker в тех случаях, когда входящий запрос должен быть обработан новым процессом.
6. Процесс employer исполняет код shm_man, когда определяет, что помог успешно создать распределенную структуру IPC для разделяемой памяти.