Ссылка на экспортируемые объекты DBus?
Я работаю над службой DBus, которая должна экспортировать объекты по требованию по запросу сторонних приложений. Эта часть кажется довольно проницаемой.
Но мне также нужно «мусор собирать» эти объекты, когда у нее есть нулевые потребители. Я мог бы иметь API, который требует, чтобы сторонние приложения явно освобождали объекты, но недостатком является то, что потребительское приложение выйдет из строя без релизов, будут накапливаться ссылки, неиспользуемые объекты.
Для чего это стоит, я используя DBus из Python через python3-dbus. Итак, у меня есть два вопроса:
Какие механизмы DBus обеспечивают подсчет ссылок на экспортируемые объекты, есть ли способ узнать, когда нулевые процессы в настоящее время «наблюдают» за объектом? Что считается лучшей практикой для разработки такого DBus API, и то, что люди считают хорошим примером для подражания? (Единственное, что я могу придумать, это объекты Avahi Browser.)Мой вопрос, вероятно, будет иметь больше смысла, если я опишу точную проблему: Dmedia - это специализированная распределенная файловая система, предназначенная для медиафайлов , Файлы получают глобально уникальный идентификатор на основе их хэша содержимого. Когда приложение должно использовать файл (скажем, для воспроизведения или отображения), он будет использовать API Dmedia DBus для разрешения идентификатора файла в обычный путь к файлу. Например, этот ID:
5PULSAF3PFR4VPNJMLSAJ362HG475NDKKISDYXW7WUJCFUJN
Могло, например, разрешить в файл:
/media/MyDrive/.dmedia/files/5P/ULSAF3PFR4VPNJMLSAJ362HG475NDKKISDYXW7WUJCFUJN
Но все сложнее. Файл может быть недоступен локально, и в этом случае Dmedia может загрузить файл с одного из других устройств пользователя или из облака. Таким образом, нам нужны сигналы для того, чтобы сказать ход загрузки, и сообщить, что этот обычный путь к файлу загружен после загрузки файла.
Разрешение также может меняться со временем, когда съемные диски подключены или отключены. Пользователь может удалить диск, после чего файл будет недоступен локально, и Dmedia попытается загрузить его. Или пользователь может подключить дополнительный диск, а разрешение заданного файла может измениться по мере перераспределения Dmedia на всех дисках.
Кажется, что объект DBus экспортирован в текущий файл -интерес - разумный подход, но, возможно, это усложняет ситуацию. Я полагаю, что это разница между необходимостью большей фильтрации и smarts на потребителя и на стороне обслуживания. Плоский набор сигналов и методов на одном объекте облегчит работу службы, но наложит больше нагрузки на пользователя.
Если мы экспортируем объект DBus в файл, представляющий интерес, Скорее всего, нам нужна сборка мусора, так как очень большое количество файлов может представлять интерес в какой-то момент жизненного цикла службы DBus.
Я бы очень признателен за любые советы по этому поводу!
1 ответ
Я столкнулся с подобной проблемой и придумал механизм для подсчета ссылок через DBus. Это оказалось довольно сложным, поэтому я создал ошибку DBus # 38784, чтобы предложить включение в спецификацию DBus в качестве стандартного интерфейса / механизма, чтобы другим не пришлось повторять работу.
Вы можете прочитать предложение в docbook формате Ошибка DBus # 38784 .
Я не верю, что это было реализовано в привязках DBU Python или любых других общедоступных привязках DBus.