LINUX.ORG.RU

Покритикуйте идею IPC

 


0

2

Приветствую.

До сих пор периодически возникает бугуртящий вопрос «ну почему D-BUS»?

Попробовал реализовать IPC через shared memory.

Итак, есть один относительно большой файл (мегабайт, или даже два, в зависимости от количества программ, его использующих).

Файл доступен через вызовы ФС, и расположен в условно говоря /dev/shm/file.

Файл в формате JSON.

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

Думаю о механизме блокировок говорить не нужно, программа не начнет обрабатывать чтение\запись до тех пор пока висит блокировка (или по тайм-ауту), а когда начнет обрабатывать - добавит уже свою блокировку, чтоб другие программы не писали.

Когда программе нужно прочитать данные - она просто читает этот файл, и достает оттуда интересующую ее переменную.

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

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

Pro системы:

Абсолютная универсальность

Любой ЯП любой степени древности имеет базовые функции работы с файловой системой, а для обыкновенной работы с этим видом IPC нужны всего лишь функция чтения, функция записи, и функция проверки существования файла.

JSON-формат прост, знаком всем, с *char работает любой ЯП, привести со своего нативного *char к своему же нужному типу - однозначно проще, чем с этих сраных variant, ss, a(sss) и прочего зоопарка велосипедов. Не говоря уже о том, что функции для парсинга JSON есть в любом современном и не очень ЯП.

Отсутствие посредника

Он попросту не нужен, посредник - сама ФС, которая уже и так есть. Кому нужно - пишет, кому нужно - читают, кому нужно - мониторят.

Соответственно небольшие накладные расходы, а значит производительность. Как ни крути, а записать в память\прочитать с памяти - намного быстрее, нежели дергать демон.

Гибкость

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

Данные не исчезают после закрытия программы, хотя запросто могут быть удалены вспомогательными сервисами, если в этом возникнет необходимость.

Понятная простота

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

- - -

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

Все пока работает.

Посмотрите пожалуйста со стороны, и покритикуйте способ.

Благодарю.

★★★★★

1) json не нужно

2) никакие таймауты блокировок тоже не нужны, это баг в чистом виде

Если нужна структурированность с текстовыми названиями - делай её через ту же файловую систему (вместо ассоциативных массивов - директории), заодно сможешь лочить отдельные переменные а не всё сразу, но и всё сразу тоже никто не запретит, локи можно и на директории делать.

Только при чём тут dbus я не знаю, dbus для пересылки сообщений делали а не для шаред переменных.

Для пересылки сообщений следует использовать unix-сокеты.

А и да, /dev/shm это обычный tmpfs, привязываться именно к этому пути незачем, можно и в другом месте сделать.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от PPP328

С чего бы это?

Во-первых, конверсии не бесконечные, а только две - после чтения и перед записью.

Во-вторых это в каком языке парсинг строки займет так много ресурсов?

В-третьих, в случае применения DBUS этот парсинг тоже существует, просто с тройным преобразованием: внутренний строковый формат, преобразуется в интерфейсный тип (тот самый AS, SS, I и тд), а с интерфейсного типа уже в тот тип что нужен тебе в твоей программе.

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

Только при чём тут dbus я не знаю, dbus для пересылки сообщений делали а не для шаред переменных.

Не существует никакой пересылки сообщений.

Есть программа №1 и программа №2.

И есть только один способ пересылки данных между ними: ШАРЕД, т.е. общая область, которую одна программа мониторит, а вторая туда пишет.

Разница только в количестве прослоек.

windows10 ★★★★★
() автор топика

а когда начнет обрабатывать - добавит уже свою блокировку, чтоб другие программы не писали.

Поздравляю, мы добились того, что в один файл долбится вся система, при этом безумно тормозя.

этот флаг можно узнать как периодически дергая дату модификации

🤦‍♂️🤦‍♂️🤦‍♂️

или inotify

Потеря информации о том, кто и что дописал с последнего обновления.

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

Программа кривая и косячная, что-то теряет при записи в файл, или вовсе пишет мусор. Дальше что? Все, что должно было быть доставлено адресату (адресатам) успешно похерено.

Для разграничения владельца, само собой формат переменных может представлять собой ассоциативный массив,

А может не представлять. Кто как нагадит.

Для разграничения владельца […] ассоциативный массив,где первый ключ - уникальное имя приложения. Шина, если по-dbus-ному.

Т.е. никакой владелец не разграничивается, все читают все – в том числе, передаваемые секреты 👍

Данные не исчезают после закрытия программы, хотя запросто могут быть удалены

Почему это хорошо? Я не хочу, чтобы убогие портянки на пхп гадили мне в систему. Кстати, «запросто» ничего удалить нельзя, т.к. в твоем замечательном IPC нет информации о том, обработаны ли хранимые записи. См. выше.

Понятная простота. Никаких интроспекций, демонов, методов, сигналов и прочего мусора.

Почему это непонятно или сложно?

Siborgium ★★★★★
()
Ответ на: комментарий от windows10

Ты совершенно не прав. Сообщение это штука, которую отправили и забыли про неё, а потом можно отправить ещё одно и ещё одно и тоже про них забыть (и не думать на своей стороне о том, как и когда та сторона его прочтёт). Шаред память это когда у тебя есть фиксированная зона, запись в которую там и остаётся до тех пор пока ты её не перезапишешь чем-то новым. Да, с помощью этого можно реализовать и очереди сообщений, но зачем это эмулятор, когда они уже есть в ядре в виде unix-сокетов нативно?

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от Siborgium

Поздравляю, мы добились того, что в один файл долбится вся система, при этом безумно тормозя.

В случае с dbus, вся система тоже долбится в одно и то же место.

Вот только я не понял, с чего вся система должна безумно тормозить? Это ж область памяти.

Потеря информации о том, кто и что дописал с последнего обновления

С чего это?

Файл обновился - его перечитали. Скорость памяти - огромна, на микросекунды уходят.

Программа кривая и косячная, что-то теряет при записи в файл, или вовсе пишет мусор. Дальше что? Все, что должно было быть доставлено адресату (адресатам) успешно похерено.

Как и в DBUS. Сигнал не прочитали вовремя - он потерялся. Ну а мусор писать программа в любой файл может, но как мне кажется, суть программирования - не писать мусор в файлы.

А может не представлять. Кто как нагадит.

Как и в DBUS. Тебе же никто не запрещает например в область трея записать не pixmap, а текст «Преступления и наказания», и тогда у тебя минимум на месте иконки отразится белиберда, либо вовсе вылетит системный трей, если нет проверки на размер.

Т.е. никакой владелец не разграничивается, все читают все – в том числе, передаваемые секреты

dbus-monitor - и читай все секреты что у тебя на локалхосте передаются.

Почему это хорошо? Я не хочу, чтобы убогие портянки на пхп гадили мне в систему. Кстати, «запросто» ничего удалить нельзя, т.к. в твоем замечательном IPC нет информации о том, обработаны ли хранимые записи. См. выше.

См ниже. Никто не запрещает тебе удалять просроченные данные. Ну а информации об обработанности нет и в dbus. Запросил метод - владелец его не обработал, все, метод потерян. Послан был сигнал, твоя программа в этот момент на 200мс подвисла - все, сигнал был утерян.

Почему это непонятно или сложно?

Потому что открой код любой программы, взаимодействующий с d-bus и посмотри какая там лапша накручена, просто чтобы прочитать пару переменных.

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

В целом, если тебе очень нужен IPC на JSON, можешь посмотреть в сторону varlink, который понемногу прикручивают в systemd в дополнение к и с потенциалом на замену D-Bus.

О !

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

Сообщение это штука, которую отправили и забыли про неё, а потом можно отправить ещё одно и ещё одно и тоже про них забыть (и не думать на своей стороне о том, как и когда та сторона его прочтёт).

Да, вот это и раздражает.

когда они уже есть в ядре в виде unix-сокетов нативно?

Затем что unix-сокеты нужно создавать, и нужно слушать. Операция прослушивания сокета в любом ЯП блокируемая, т.е. программа по сути подвисает (в принципе как и с d-bus). А значит нужно внедрять лишнюю сущность в виде потоков. Что влечет за собой необходимость обмениваться данными уже с потоком, слушающим сокет. Программа распухает.

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

dbus - это ещё и rpc и интроспекия

Интроспекция - это костыль, призванный описать структуру - и по сути НЕ НУЖНЫЙ.

Если мне нужно дернуть метод какой-то программы, я его и так знаю.

А если мне нужно описать структуру моей программы - так это является еще большим бредом. Все равно что к структуре каталогов прилагать файл с XML-описанием структуры каталогов.

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

В случае с dbus, вся система тоже долбится в одно и то же место.

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

Вот только я не понял, с чего вся система должна безумно тормозить? Это ж область памяти.

На каждое изменение все слушатели в системе будут подняты по inotify, и пойдут одновременно долбиться в файл. В файл успеет только один из них, остальные в лучшем случае вернутся к своим делам, либо заблокируются и будут ждать. Так будет повторяться после каждого изменения.

Не говоря уже о том, что каждый раз перечитывать одну и ту же в лучше случае мегабайтную портянку в лучшем случае валидного JSON’а и сравнивать с тем, что было – дорого. Еще и выкидывать 99% этого файла, как нерелевантную для программы информацию.

Потеря информации о том, кто и что дописал с последнего обновления

С чего это?

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

Программа кривая и косячная, что-то теряет при записи в файл, или вовсе пишет мусор. Дальше что? Все, что должно было быть доставлено адресату (адресатам) успешно похерено.

Как и в DBUS. Сигнал не прочитали вовремя - он потерялся.

В D-Bus мусор получит только адресат сообщения. Мусор при этом должен минимально напоминать валидное сообщение, чтобы его мог обработать брокер. В твоей системе одна программа с ошибкой будет портить IPC всему, чему не повезло через эту систему общаться.

Ну а мусор писать программа в любой файл может, но как мне кажется, суть программирования - не писать мусор в файлы.

Суть программирования – проектировать вменяемые системы.

Как и в DBUS. Тебе же никто не запрещает например в область трея записать не pixmap, а текст «Преступления и наказания», и тогда у тебя минимум на месте иконки отразится белиберда, либо вовсе вылетит системный трей, если нет проверки на размер.

Вылетит трей, а брокер и другие участники общения, не связанные с треем – не вылетят.

dbus-monitor - и читай все секреты что у тебя на локалхосте передаются.

Это функция брокера, не связанная с приемом и передачей информации.

См ниже. Никто не запрещает тебе удалять просроченные данные.

У тебя нет никаких просроченных данных, потому что у тебя нет ни таймаутов, ни отметок об окончании обработки адресатом данных, ничего. Поэтому ничего удалить ты не можешь.

Потому что открой код любой программы, взаимодействующий с d-bus и посмотри какая там лапша накручена

Открыл. Вербозно – да. Сложно – нет.

Siborgium ★★★★★
()
Ответ на: комментарий от windows10

Да, вот это и раздражает.

Что именно раздражает? То что не надо писать лишний код для обслуживания очереди вручную и вообще не надо про неё думать? Ты, кажется, вообще не понимаешь зачем нужны сообщения.

Операция прослушивания сокета в любом ЯП блокируемая, т.е. программа по сути подвисает (в принципе как и с d-bus).

Что ты несёшь?! ЯП тут ни при чём, прослушивание сокета это апи операционной системы. И нет, оно не обязательно блокируемое, всё на твой выбор.

А значит нужно внедрять лишнюю сущность в виде потоков

Омг, бредни усугубляются.

Вобщем, изучи вопрос сначала, а то у тебя ерунда какая-то в голове.

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

Что именно раздражает? То что не надо писать лишний код для обслуживания очереди вручную и вообще не надо про неё думать? Ты, кажется, вообще не понимаешь зачем нужны сообщения.

В dbus-нет никаких сообщений. Есть вызов метода, есть просмотр свойства, есть мониторинг сигнала. А раздражает вот это «послал и забыл», и пофиг успеет программа это увидеть, или нет.

Что ты несёшь?! ЯП тут ни при чём, прослушивание сокета это апи операционной системы. И нет, оно не обязательно блокируемое, всё на твой выбор.

ЯП тут при том, что программа как ни странно пишется в ЯП.

И конечно же оно блокируемое, потому что других способов понять что в сокет что-то пришло, кроме висения на нем - нЭд.

https://man7.org/linux/man-pages/man2/accept.2.html

Цитирую:

 If no pending connections are present on the queue, and the socket
       is not marked as nonblocking, accept() blocks the caller until a
       connection is present.

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

Вобщем, изучи вопрос сначала, а то у тебя ерунда какая-то в голове.

В этом и дело, что после изучения вопроса я понял что d-bus написали откровенные идиоты.

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

с потенциалом на замену D-Bus.

dbus насколько глубоко проник в кишки люнексового десктопа, что его оттуда выкинуть практически невозможно будет. Переход на что-то новое будет сравним с переходом на Wayland и так же затянется на 20 лет, после чего все со всеми пересрутся.

hateyoufeel ★★★★★
()

Так до D-BUS, создавали файлы сокеты, и fifo для взимодействия. И да вариант json вместо xml D-BUS хорошая идея, но кто будет твоим вариантом пользоватся: либо D-BUS, либо свой fifo.

s-warus ★★★★
()
Ответ на: комментарий от windows10

В dbus-нет никаких сообщений. Есть вызов метода, есть просмотр свойства, есть мониторинг сигнала. А раздражает вот это «послал и забыл», и пофиг успеет программа это увидеть, или нет.

Сомневаюсь. dbus-monitor их показывает. Вероятно они там сделаны плохо, но это пофиг. В unix-сокетах зато всё хорошо.

ЯП тут при том, что программа как ни странно пишется в ЯП.

ЯП не влияет на работу ядра ОС, а сокеты обрабатывает именно оно. В ЯП будет только интерфейс к ядру, то есть способ сделать сисколл. Сам же сисколл работает так как сделали авторы ядра и от ЯП не зависит.

Если же сокет помечен как nonblocking

Не «если же», а разумеется помечен, если нет веских причин делать иначе.

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

Ты опять несёшь чушь. Повторю, изучи вопрос.

В этом и дело, что после изучения вопроса я понял что d-bus написали откровенные идиоты.

dbus ненужно, согласен. Но про сокеты ты не в теме.

firkax ★★★★★
()
Ответ на: комментарий от windows10

И конечно же оно блокируемое, потому что других способов понять что в сокет что-то пришло, кроме висения на нем - нЭд

man select. Подсказка - если сокет listening, то select определит его как имеющего событие для обработки, а accept при успешном возврате селекта сразу вернет сокет коннекта, и ничего не заблокируется.

no-dashi-v2 ★★★★
()
Ответ на: комментарий от Saakx

Я тоже поддельный. Но теоретически DBus можно прокинуть с машины на машину, а всё что только в памяти - нельзя.

Используя БД - не знаю.

По моему методу - можно, у меня же доступ средствами ФС.

Более того, можно даже широковещательно.

windows10 ★★★★★
() автор топика

Итак, есть один относительно большой файл (мегабайт, или даже два, в зависимости от количества программ, его использующих).

Файл доступен через вызовы ФС, и расположен в условно говоря /dev/shm/file.

Файл в формате JSON.

А чем тебя тогда сокеты не устраивают? Кидаешь IO буфер и гоняешь через сокет. Универсальности ещё больше - лёгким движением руки у тебя получается TCP/IP сокет.

Shadow ★★★★★
()

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

какой-то кастрированный и четвертованный registry, без правил и соглашений, текстом json и перезаписью всей базы на каждый чих.

и покритикуйте способ.

как критиковать, если тут нет ничего что можно принять ? то есть в «идее» хреново вообще всё

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

какой-то кастрированный и четвертованный registry, без правил и соглашений, текстом json и перезаписью всей базы на каждый чих.

Кстати да, немного отдает etcd. Может автору он нужен?

skyman ★★★★
()
Ответ на: комментарий от Shadow

А чем тебя тогда сокеты не устраивают? Кидаешь IO буфер и гоняешь через сокет. Универсальности ещё больше - лёгким движением руки у тебя получается TCP/IP сокет.

Тем что сокет создается программой и обслуживается программой. Вопрос же не во взаимодействии программы1 с программой2, а всех со всеми.

Программа завершилась, сокет остался но не обслуживается. С памятью\ФС такого сценария не будет.

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

Кстати да, немного отдает etcd. Может автору он нужен?

Автор всего лишь экспериментирует с более простыми способами IPC, нежели d-bus =)

Ему не нужно что-то конкретное. Все уже работает на d-bus. Но вдруг можно правильнее, а не через данную жопу.

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

какой-то кастрированный и четвертованный registry, без правил и соглашений, текстом json и перезаписью всей базы на каждый чих.

Ну файловая структура же как-то работает без правил и соглашений. Да, ее можно поломать. Но никто же сознательно её не ломает.

Кастрированный - это да. От IPC это и требуется - быстро передать сообщение от одного к другому, или другим. Без интроспекций, сигналов, методов, свойств, кучи полей с вариантами и несовместимыми между собой типами.

Должен быть один кастрированный тип - *char. Остальные должны просто получить этот *char одной строкой и перевести нативно в то, что нужно им самим, не задействуя костыли на велосипедах.

Я вообще удивляюсь как можно было нахардкодить в такой простой концепции как межпроцессное взаимодействие.

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

Запросов на чтение и запись в этот файл. Олло, мущина, не нужно применять доисторические технологии, если вы не выживальщик.

Окей, если можно - ссылку на реализацию на FreePascal пажалста.

windows10 ★★★★★
() автор топика

во-первых это не решение проблемы. Если все данные в одном файле, то на каждый коллбек inotify будут просыпаться все. И потом видимо парсить, не изменилось ли у них чего.

Во-вторых, писать пост с помощью нейронки - моветон.

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

Идея, что дыбас не нужен - тоже здравая. На кой черт нужен лишний демон, который может упасть и тогда твое IPC превратится в тыкву, когда клиенты и сервера могут слать друг другу сообщения напрямую через сокет? Тот же вяленый тому примером. Или ssh.

Lrrr ★★★★★
()

Постановка вопроса максимально расплывчатая, а предлагаемое решение максимально заточенное под конкретный юз-кейс. Поэтому всё это для меня звучит странно.

Для меня IPC в первую очередь это обмен сообщениями. Обмен сообщениями через общий JSON реализовать, конечно, можно, но это будет максимально странно. Я бы предпочёл сокеты.

Если ты хочешь сделать аналог реестра Windows - такой вариант может быть неплох.

В целом я считаю, что нормальный IPC должен включать в себя сервер. Например что будет, если в твоём варианте программа, записывающая JSON, упадёт в середине? Получится недописанный JSON. Остальные попробуют его прочитать и тоже упадут. Ерунда какая-то. Нужен кто-то, кто будет валидировать входящие значения. Когда мы начали говорить про валидацию входящих значений, тут сразу возникает много уровней валидации. Валидация того, что это валидная UTF-8 строка. Валидация того, что это всё валидный JSON. Валидация того, что в этом JSON правильная структура. Валидация того, что значения в этой структуре соответствуют каким-то ограничениям. И тд. Т.е. сразу уже захочется делать какие-то формальные описания, например на основе JSON Schema. Потом генерировать код по этой схеме. И, кажется, приезжаем к тому же, от чего уезжали.

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

При этом вполне допускаю, что dbus ужасен, хотя я с ним никогда не работал, но в линуксе всё, с чем я сталкивался, сделано максимально плохо. Но это не значит, что его идеи неправильны. По-хорошему IPC должен быть черед ядерные примитивы. Вроде недавно из Андроида заапстримили Android Binder в линукс. Попробуй посмотреть на него, вдруг понравится.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от windows10

я понял что d-bus написали откровенные идиоты.

дбас писали чтоб скринсейвер не включался пока ты кино на десктопе смотришь. А вот зачем его везде тащат как стандарт IPC вплоть до эмбеда – это да

pihter ★★★★★
()
Ответ на: комментарий от vbr

как я выше писал, есть хорошие ядерные примитивы для IPC, да dbus не очень, Android Binder к сожалению не знаю, думаю он тоже linux примитивы использует, а так я с mpd через state_file общаюсь, и для своих костылей сокет файл создаю.

s-warus ★★★★
()
Ответ на: комментарий от hateyoufeel

Я конечно не могу говорить за всех, но у меня с ним вообще никаких проблем не было после того как завезли wireplumber.

ptah_alexs ★★★★★
()
Последнее исправление: ptah_alexs (всего исправлений: 1)
Ответ на: комментарий от ptah_alexs

Я конечно не могу говорить за всех, но у меня с ним вообще никаких проблем не было после того как завезли wireplumber.

Ты просто не делаешь ничего интересного.

Мой сценарий: у меня тут джойстик от PS5, в нём есть в том числе аудио-чип для наушников и микрофона. Прикол джойстика в том, что он любит, когда подключен по кабелю, отваливаться и переподключаться на каждый чих по нескольку раз. От этого Pipewire вешается и тупо перестаёт отдавать звук.

Ну и каноническое, при подключении звука по BT его иногда надо перезагружать по пять раз чтобы всё заработало. Но тут, может быть, проблема в том, что BT – самый дебильный беспроводной протокол на рынке сейчас, и всё что с ним связано – дико проклято.

hateyoufeel ★★★★★
()

хочешь повернуть время вспять? :-))) dbus пришёл на смену именно подобным IPC. Самая большая проблема тут - каждая программа должны быть написана правильно. Т.е. правильно использовать блокировку, парсинг и т.п. и при любой ошибке записи или блокировке весь конфиг отправляется в лучшем случае в /dev/null, а в худшем там будет каша. «Надо написать библиотечку!», под каждый яп? теряем универсальность. А как мониторить изменение параметра из java? По таймеру парсить метровые файлы? А как сделать безопасность? Ну и в целом в конце пути у тебя будет что-то вроде dbus, только ещё более кривой.

vtVitus ★★★★★
()