1 гуй, 2 программы

а обычные пайпы чем не подходят?

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

синхронный вызов прямо из GUI? Тебе нельзя программировать.

В общем, есть 2 программы, есть 2 gui обертки. При нажатии кнопки в обертке1 отсылается команда «завари чай» программе2. Программа2 выполняет и результат помещает в некоторое хранилище, в котором обертка1 и обертка2 могут узнать состояние выполнения команды «завари чай» и результат ее выполнения. Но обертка1 и обертка2 могут не просто узнать состояние, но и вопользоваться результатом выполнения команды при необходимости (например, показать лейбл - «чай заварен»). Мне кажется, что под эту задачу подходит dbus, но насколько будет производительным данная реализация? Сейчас подробнее разберусь с пайпами, про которые упомянули в 1-ом коменте. Есть ли еще возможные решения?

RPC.

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

Просто добавь воды третью программу которая будет раздавать/принимать задачи через popen() из/в две других программы, а гуй будет просто выводить что там ему выдал этот импровизированный «сервер». А «сервер» для общения с гуем пусть использует сокеты, причём два один для отдачи команд, другой для получения результатов.

zeromq+msgpack

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

Возможно ли реализовать это через dbus?

Qt, например, умеет такое из коробки:

http://doc.qt.io/qt-5/qtdbus-index.html

Яп - rust.

Е%сь с этой х%йней сам, сын мой. (с)

ØMQ

Плюсую, тоже не понял в чем проблема просто заюзать пайпы.

Ну дбас быстр можно конечно и его.

Гуй тоже на расте пишешь?

Через dbus ничего никогда не нужно реализовывать. Делай через обычный pipe как сказали.

Все на десктопе делается через dbus. Насколько часто будут делаться такие запросы? Если часто, то почему не отправлять сразу много запросов в одном DBus вызове?

Иди гуляй

кстати, насколько производительны пайпы?

достаточно производительны

а где бы почитать про их оверхеад и вообще, как оно внутри?

в исходниках ядра, очевидно же :)

ну а если пропускной способности пайпов недостаточно, тогда используют shared memory

слишком долго

На столько, что ты в оперции с ними не упрешся. Упрешься, скорее всего, в анализ того, что поступает через них, чем в IO операции с ними.

а вообще ТС, ты не написал, что эти две программы делают, как общаются с внешним миром

Про возможные варианты взаимодействия программ между собой и когда что следует выбирать можно почитать в The Art of Unix Programming

Пример: нужно получить список файлов в директории и выдать обертке результат, чекбоксом управлять состоянием программы - задачи тривиальные, необходимо лишь отсутствие видимых задержек (получения/отправки) работы графической обертки. Всё это внутри одной ОС, но если dbus предоставляет возможности работы гуя по сети - лишним точно не будет.

Дык напиши тест на 1000/10000/100000 запросов через пайпы да глянь

только он будет для моего компа объективен. но можно попробовать.

если файлов много, то получение списка может происходить с ощутимой задержкой, так что или select/poll или в отдельном от гуя потоке

Стоит ли рассматривать вариант использования уже готовых программ: ls, mkdir?

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

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

Т.е. по делу даже буквы не нашлось?

Это у тебя не нашлось. Не осилил dbus - не учи гадостям окружающих

Попробуйте D-Bus. Если объёмы передаваемых данных не слишком большие, и частота не слишком высокая, D-Bus подойдёт.

Стоит сперва попробовать D-Bus, если что-то будет тормозить - переписать эту часть с использованием более низкоуровневых средств IPC.

Насколько объем и частота должны быть большими? Возьмем пример парсера имен файлов в каталоге.

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

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

Лучше строкой через разделители гнать имена файлов или через массив? Ограничена ли строка?

1. Как вам удобнее.

2. Согласно спецификации:

The maximum length of a message, including header, header alignment padding, and body is 2 to the 27th power or 134217728 (128 MiB). Implementations must not send or accept messages exceeding this size.

http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-messages

1. В плане производительности что оптимальнее использовать?

Точно ответить не могу, нужно проверить.

Но сначала выяснить, нужна ли такая микрооптимизация в данном проекте?

Ладно, можно попробовать вынести весь функционал в библиотеки..

1. Я правильно понимаю, что при старте программы1 стартует его динамически слинкованная библиотека. Пока программа1 запущена, в памяти висит его зависимость. Запускаем программу2, ей тоже нужна эта библиотека и она пользуется той, что уже в памяти?
2. Велика ли разница в производительности будет: вызывать методы из библиотеки VS вызывать методы через dbus? А если из kdbus? Каков будет оверхед?

1. В Linux - да, именно поэтому динамические библиотеки ещё и называют разделяемыми.

2. Через библиотеку быстрее конечно, чем через IPC. IPC нужны для обмена данными между разными процессами. Overhead будет из за копирования данных в ядро и обратно, а также из за сериализации/десериализации данных. При вызове метода данные передаются из программы-клиента демону D-Bus, затем от демона D-Bus программе-сервису, обратно они тоже передаются через демон.

С переходом на kdbus overhead частично исчезнет. Предварительные тесты показывают интересные результаты: http://ru.fedoracommunity.org/content/Первые-бенчмарки-kdbus