Подсчет ссылок на экспортированные объекты DBus?
Я работаю над службой DBus, которая должна экспортировать объекты по запросу по запросу сторонних приложений. Эта часть кажется довольно прямой.
Но мне также нужно «собрать мусор» этих объектов, когда у него нет потребителей. У меня мог бы быть API, который требует, чтобы сторонние приложения явно освобождали объекты, но недостатком является то, что если пользовательское приложение аварийно завершает работу без освобождения ссылок, могут накапливаться неиспользуемые объекты.
Для этого я использую DBus из Python через python3-dbus. Итак, у меня есть 2 вопроса:
-
Какие механизмы DBus предоставляет для подсчета ссылок на экспортируемые объекты, есть ли способ узнать, когда нулевые процессы в настоящее время «наблюдают» за объектом ?
-
Что считается наилучшей практикой для разработки такого DBus API, и что люди считают хорошим примером для подражания? (Единственное, о чем я могу думать, это объекты Avahi Browser.)
Мой вопрос, возможно, будет более понятным, если я опишу точную проблему: Dmedia специализированная распределенная файловая система, предназначенная для медиафайлов. Файлам присваивается уникальный глобальный идентификатор в зависимости от их хэш-содержимого. Когда приложению необходимо использовать файл (например, для воспроизведения или отображения), оно будет использовать API Dmedia DBus для преобразования идентификатора файла в обычный путь к файлу. Например, этот идентификатор:
5PULSAF3PFR4VPNJMLSAJ362HG475NDKKISDYXW7WUJCFUJN
Например, может быть преобразован в файл:
/media/MyDrive/.dmedia/files/5P/ULSAF3PFR4VPNJMLSAJ362HG475NDKKISDYXW7WUJCFUJN
Но все гораздо сложнее. Файл может быть недоступен локально, и в этом случае Dmedia может загрузить файл с одного из других устройств пользователя или из облака. Таким образом, нам нужны сигналы, скажем, о прогрессе загрузки и о том, какой путь к файлу обычно используется после загрузки файла.
Разрешение также может изменяться со временем, когда съемные диски подключены или отключены. Пользователь может удалить диск, после чего файл не будет доступен локально, и Dmedia попытается загрузить его. Или пользователь может подключить дополнительный диск, и разрешение данного файла может измениться в результате перебалансировки нагрузки Dmedia между дисками.
Кажется, что экспорт объекта DBus для текущего файла интереса - разумный подход, но, возможно, это делает вещи слишком сложными. Я полагаю, что это разница между потребностью в большей фильтрации и умом на стороне потребителя по сравнению с сервисом. Плоская совокупность сигналов и методов на одном объекте облегчит обслуживание, но будет более обременительной для потребителя.
Если мы экспортируем объект DBus для каждого интересующего файла, я уверен, что нам понадобится сборка мусора, так как очень большое количество файлов может представлять интерес в некоторый момент в течение жизненного цикла службы DBus.
Буду очень признателен за любые советы по этому поводу!
2 ответа
Во-первых, вероятно, стоит распаковать, что означает «наблюдение» в:
Какие механизмы предоставляет DBus для подсчета ссылок на экспортируемые объекты, есть ли способ узнать, когда в настоящее время находятся нулевые процессы «наблюдать» за объектом?
Единственный смысл, в котором имеет смысл спрашивать, «наблюдает» ли что-либо за объектом DBus, заключается в том, получит ли клиент какие-либо сигналы, которые вызывает этот объект; в противном случае нет понятия наблюдения, просто передача сообщений. Клиенты делают это, вызывая AddMatch / RemoveMatch на шине, чтобы вы могли теоретически сосчитать ссылки на совпадения. Это похоже на метод, подверженный ошибкам - вам, в основном, нужно переопределить обработчик совпадений демона, чтобы убедиться, что вы уловили все способы, которыми клиент может прослушивать ваши сигналы.
Однако, если все, что вам нужно, это очистка после сбоя клиентов, есть способ - каждый клиент DBus получает уникальный идентификатор шины (например,
:1.693), назначенный ему демоном. Когда клиент запрашивает файл через API-интерфейс DBus, вы можете записать его идентификатор шины, а затем просмотреть сигналNameOwnerChangedизorg.freedesktop.DBus. Этот сигнал состоит из 3 частей - имени шины (которая в интересующих нас случаях будет уникальным идентификатором шины), идентификатора шины нового владельца и идентификатора шины старого владельца.Таким образом, если вы получаете сигнал
NameOwnerChangedсname=":1.693",new_owner=""иold_owner=":1.693", вы знаете, что клиент с идентификатором шины:1.693отключился от шины и может удалить любые объекты, которые клиент использовал.Вы хотели бы сделать это в дополнение к , чтобы клиенты явно сообщали вашей службе, когда они закончили с файлом, конечно.
Редактировать:
Что касается вашего глобального вопроса - каким должно быть API - я бы предположил, что это кажется достаточно сложным, чтобы ваши объекты DBus должны были [ 1112] не быть основным API. Оберните это в
python-dmedia-client(и, возможно, в Clibdmedia-client), и обработайте пересчет и сложность там.
Я столкнулся с подобной проблемой и разработал механизм подсчета ссылок в DBus. Это оказалось довольно сложно, поэтому я создал ошибку DBus # 38784 , чтобы предложить включение в спецификацию DBus в качестве стандартного интерфейса / механизма, чтобы другим не пришлось повторять работу.
Вы можете прочитать предложение в формате docbook здесь .
Я не верю, что это было реализовано в привязках DBus Python или любых других общедоступных привязках DBus.