The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Архитектурные проблемы systemd, негативно влияющие на стабил..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Присылайте удачные настройки в раздел примеров файлов конфигурации на WIKI.opennet.ru.
. "Архитектурные проблемы systemd, негативно влияющие на стабил..." –1 +/
Сообщение от Xasd (ok), 13-Фев-14, 01:16 
> Просьба к Xasd.

если существует определённая <сложность> -- то она обязательно будет где-то реализованна. вопрос -- "где?".

[1] ваше предложение:

пускай /init будет реализован как можно проще без <сложностей> (и работает безотказно), но при этом вся <сложность> перейдёт внутрь демонов, которые запускаются через /init.

[2] предложение systemd:

часть <сложности> будет перенесено из демонов -- внутрь /init. но этот /init будет хорошо отлажен.

итог: в чём разница на практике(?):

в том что в случае [2] -- нужно отлаживать /init -- его <сложность> (и ТОЛЬКО его <сложность>)! например достаточно исправить только 1 ошибку которая может казаться внутри <сложности> /init -- и эта ошибка уже НЕ появится внутри ВСЕХ демонов.

в случае [1] -- так как <сложность> находится внутри каждого демона -- то высока вероятность что разрабочики каждого из демонов будут наступать всякий раз на одни и теже грабли, допуская примерно одинаковые ошибки внутри реализации своих <сложностей>.

в случае [1] -- суммарное число кода больше, и суммарная <сложность> всей системы больше, так как каждый демон реализовывает <сложность> поновой ещё раз.

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

простой пример -- операция fork() является двольно опасная (дочерние нити Threads -- не клонируются во время fork, но при этом клонируются все состояния примитивов синхронизации). если сделать fork() неосторожно -- то можно в итоге наткнуться на редкий случай зависания. разработчик демона -- может допустить ошибку с fork() очень легко, и очень долго её не замечать [а редкие случаи зависания закрывать в багрепортах -- как not_confirmed]. некоторое библиотеки тоже начинают криво работать после fork() [допустим разработчик демона не совершал ошибок, но разработчик библиотеки накосячил слегка когда не думал о том что кто-то будет использовать fork()].

systemd позволяет не использовать fork() для старта демона [но при этом получить сигнал о том, успешно ли стартонул демон].

ну и кроме fork() -- разумеется systemd решает и другие <сложности>. материала на эту тему есть в избытке. просто привёл один из наиболее примитивных примеров.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Архитектурные проблемы systemd, негативно влияющие на стабил..., opennews, 10-Фев-14, 10:18  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру