Lennart Poettering в рассылке [email protected] к конце прошлого года анонсировал общую готовность kdbus и предложил начать процесс портирования приложений с библиотеки dbus1 на kdbus. Как обычно, предложение вызвало волну обсуждений - почему kbdus требует systemd? что будет с D-Bus под Windoz и Mac OS X? будет ли включена поддержка kdbus в GNOME и KDE? почему GVariant как wire-protocol формат? и т.п. Lennart постарался на все ответить, и, хотя было видно, что часть участников обсуждения из Canonical недовольны ситуацией, в целом обсуждение было конструктивно и полезно.

Из особенно полезного, инженер Samsung, Lukasz Skalski, который работает над включением kdbus в glib, сообщил, что провел серию бенчмарков kdbus и D-Bus. Из тестов складывается очень интересная картина (чем меньше, тем лучше):

Message size	Elapsed time GLIB WITH KDBUS SUPPORT	Elapsed time GLIB + DBUS DAEMON
1000 x 4kB	1.351737 s	1.870417 s
1000 x 8kB	1.349266 s	1.857693 s
1000 x 16kB	1.383427 s	2.219304 s
1000 x 32kB	1.358608 s	2.542795 s
1000 x 64kB	1.878409 s	3.062035 s
1000 x 128kB	2.265555 s	4.043454 s
1000 x 256kB	3.112191 s	6.657750 s
1000 x 512kB	3.383699 s	11.400224 s
1000 x 1MB	4.703610 s	19.041988 s

Видно, что квадратичного роста времени отклика в зависимости от размера сообщения почти удалось избежать (с превышением 32 килобайт, что является текущим практическим лимитом для приложений, использующих D-Bus, отклик начинает медленно и почти линейно расти). Таким образом, становится возможным начинать осторожно использовать kdbus, как полноценную шину данных, скрепляя компоненты системы не пайпами, линкуя их с букетами библиотек, или как-то еще, а с помощью message passing (типизованными сообщениями) через kdbus. Это теоретически повысит надежность всей системы, и у нас постепенно появляется возможность сильнее изолировать runtime-компоненты. Практически Unix-way Reloaded!