LINUX.ORG.RU

архитектура демона


0

0

Добрый день!

Есть задача написать некоторый демон, он считывает некоторый конфигурационный файл и, следуя ему, начинает слушать некоторые источники информации и записывать в области общей памяти. Каждому источнику информации соответствует некоторая область памяти. Я думаю сделать так: для каждой такой пары порождать процесс fork-ом, и в каждом подпроцессе создавать область памяти и прослушивать источник. В каждом из потомков может что-то случиться, поэтому было бы хорошо, чтобы главный процесс получал оповещение о смерти потомков и мог его перезапускать. Нормально ли использовать такой подход? Может быть есть примеры в каких-то проектах?


Почему нет. Родительский процесс занимается лишь управлением дочерними процессами. В основном цикле тупо сидит и ждет в waitpid() и делает, что ему скажут.

bibi
()

>Нормально ли использовать такой подход?
зависит от конкретных условий: количество «источников информации», ограничения по потребляемым ресурсам. В общем случае вполне нормальная модель.

nu11 ★★★★★
()

>начинает слушать некоторые источники информации

Звучит так, словно топискстартер никогда не слышал о select/poll/epoll/kqueue

linuxfan
()
Ответ на: комментарий от mv

Дело в том, что каждый из процессов может блокироваться после приема информации (во время обработки) и из-за этого не давать читать информацию из других источников, что не есть хорошо. Можно, конечно, исхитряться и придумывать хитрые обходные пути, но хочется сделать попроще. К тому же, могут возникать исключительные ситуации и некоторую пару проще убить/перезапустить. Все это можно вместить в один процесс, но тогда придется его очень хитро планировать, а хочется сделать просто и надежно :)

cs
() автор топика
Ответ на: комментарий от cs

Дело в том, что каждый из процессов может блокироваться после приема информации (во время обработки) и из-за этого не давать читать информацию из других источников, что не есть хорошо. Можно, конечно, исхитряться и придумывать хитрые обходные пути, но хочется сделать попроще. К тому же, могут возникать исключительные ситуации и некоторую пару проще убить/перезапустить. Все это можно вместить в один процесс, но тогда придется его очень хитро планировать, а хочется сделать просто и надежно :)

Но почему процесс а не поток? Последние исключили бы гемор с разделяемой памятью.

bibi
()
Ответ на: комментарий от bibi

Разделяемая память используется не для взаимодействия родственных процессов, но для предоставления информации другим процессам-потребителям, которые не родственны описанному демону.

cs
() автор топика
Ответ на: комментарий от cs

Разделяемая память используется не для взаимодействия родственных процессов, но для предоставления информации другим процессам-потребителям, которые не родственны описанному демону.

Понятно. Что, впрочем, не налагает никаких ограничений на внутреннее устройство демона и само по себе не обязывает его порождать процессы а не потоки :)

bibi
()

исходя из начальных требований, а также из последующих пояснений - потоки+nonblocking. ну а дальше из прикладных предпочтений - селекты, пулы и тд. городить процессы - имхо зло. Единственное и оправданное решение в пользу процессов - обезопасить себя от сегфолтов этих «дочерних» процессов. В этом случае да, плодимся и пользуемся любым из подходящих IPC.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.