https://opennet.dev/openforum/vsluhforumID3/101700.html Грег Кроа-Хартман (Greg Kroah-Hartman) опубликовал (https://lkml.org/lkml/2015/3/9/340) четвёртую версию патчей с реализацией kdbus, реализованной на уровне ядра Linux надёжной, быстрой и безопасной системы обмена сообщениями, поддерживающей доставку сообщений в режиме точка-точка и в режиме мультикаст (от одного отправителя к группе получателей). Kdbus может использоваться не только для альтернативных реализаций D-Bus, не требующих запуска отдельного демона в пространстве пользователя, но и в виде самодостаточного IPC, например, данная система уже поддерживается в systemd. <br><br><br><br>Система D-Bus является универсальной шиной, нашедшей широкое распространение в дистрибутивах Linux. При этом ключевыми недостатками данной системы, обусловленными реализацией D-Bus в пространстве пользователя, является слишком низкая скорость передачи сообщений и неприменимость для приложений, предъявляющих повышенные требования ко времени задержки доставки сообщений. Из-за высоких задержек D-Bus собственные реализации транспортного https://opennet.dev/openforum/vsluhforumID3/101700.html#68 Thu, 12 Mar 2015 14:46:17 GMT &gt; Поэтому синхронные вызовы - к ядру - норма, а вот к юзерспейсу - не норма ни разу.<br><br>Как мне нравятся ваша безапелляционность и уверенный тон. Кроа-Хартман, перелогиньтесь.<br> https://opennet.dev/openforum/vsluhforumID3/101700.html#67 Wed, 11 Mar 2015 13:55:02 GMT Последние пару лет их туда не брали. Будем надеяться, что и не возьмут.<br> https://opennet.dev/openforum/vsluhforumID3/101700.html#66 Wed, 11 Mar 2015 10:10:17 GMT Это логотип Росбанка<br> https://opennet.dev/openforum/vsluhforumID3/101700.html#65 Wed, 11 Mar 2015 08:32:41 GMT D-Bus появился раньше<br> https://opennet.dev/openforum/vsluhforumID3/101700.html#64 Tue, 10 Mar 2015 21:47:27 GMT &gt; Но я очень хорошо представляю архитектуру, где практически всё бы работало через <br>&gt; него, а до тех же пайпов разве что оптимизировались бы автоматом <br>&gt; отдельные частные случаи. Что, в частности, означало бы, что у ЛЮБОЙ <br>&gt; гуёвой софтины гарантированно есть программный интерфейс, который может не меньше, чем <br>&gt; гуй.<br><br>Мысль интересная. Но к каждому GUI нужно будет прикрутить управление через эту шину + способ получение элементов (widget) GUI доступных на данный момент. Будут сложности с организацией автомотизированной работы: придется ждать появления новых окон и правильно обрабатывать неожиданно возникшие окна и запросы. Ломаться совместимость будет часто - GUI изменяют чаще, чем cli.<br><br>Но главное, что это реально даст? Насколько это решение может быть оправдано и полезно? Будут ли реальные преимущества, против применяемого на данный момент подхода (backend + frontend, backend as lib + frontend)? <br><br>&gt; Причём стандартизированный, в отличие от миллиона форматов сокетов и вывода <br>&gt; в stdout. И да, я https://opennet.dev/openforum/vsluhforumID3/101700.html#63 Tue, 10 Mar 2015 20:56:47 GMT Не смущает, что на другой ноде оригинальные юзер и pid не несут вообще никакого смысла, если не сделать специальную логику по синхронизации этого дела? А это написать - уже ни разу не 15-20 минут. Тут продумать, как это вообще должно мапиться и управляться - и то дольше.<br> https://opennet.dev/openforum/vsluhforumID3/101700.html#62 Tue, 10 Mar 2015 20:51:05 GMT Шина - это копеечные затраты ресурсов. И обрати внимание - я ж спецально оговорил - "если подойдут параметры". Просто потребление ресурсов - это только один из факторов, влияющих на пригодность или непригодность решения.<br><br>У меня самого D-Bus нет (откуда ему быть - без DE, пульсов и прочего подобного?). Потому что для моих нужд больше подходит софт, авторы которого курили меньше конопли, чем авторы третьегнома или Потеринг. Ну, или конопля у них была лучше ;-)<br><br>Но я очень хорошо представляю архитектуру, где практически всё бы работало через него, а до тех же пайпов разве что оптимизировались бы автоматом отдельные частные случаи. Что, в частности, означало бы, что у ЛЮБОЙ гуёвой софтины гарантированно есть программный интерфейс, который может не меньше, чем гуй. Причём стандартизированный, в отличие от миллиона форматов сокетов и вывода в stdout. И да, я бы очень хотел заменить POSIX на такую штуку.<br><br>И если ради такой унификации окажется, что видео тоже через D-Bus летает (и, соответственно, его можно пр https://opennet.dev/openforum/vsluhforumID3/101700.html#61 Tue, 10 Mar 2015 20:35:07 GMT именно. А юзерспейс на другой её стороне - вполне может творить что угодно. И если от этого ещё и процесс, инициировавший вызов зависнет - это ни разу не правильно, и у яюра нет libastral чтобы знать, как это разруливать. Поэтому - только асинхронные события на шине, а если нужна синхронность - реализовывать руками, с той логикой обработки нештатных ситуаций, которая подходит для данного случая. Особенно учитывая, что для большинста случаев использования IPC синхронность абсолютно не нужна.<br> https://opennet.dev/openforum/vsluhforumID3/101700.html#60 Tue, 10 Mar 2015 20:30:41 GMT Ну так о том и речь. Поэтому синхронные вызовы - к ядру - норма, а вот к юзерспейсу - не норма ни разу.<br>