Тут стал мне любопытен Go (Golang)... почитал, попробовал - ну довольно интересные концепции... но на чем-то надо было попробовать.....
Взял да и попробовал повторить обертку для yandex-disk, благо на питоне это уже все отлажено было в индикаторе (класс YDDaemon).
В индикаторе есть низкоуровневый класс YDDaemon. Он мониторит изменения состояния демона и отвечает за передачу команд демону.
За UI (сам индикатор в панель, меню и диалоги) реализуются классом Indicator, который наследуется от YDDaemon.
Благодаря наследованию появляется возможность передачи команд демону и получение изменений его статуса через call-back вызовы.
Собственно немного экспериментов с GO, и я получил все "прелести" реально много-поточного кода: data racing или гонки обновлений.
В Python (cpython) есть GIL - некая такая чаша Грааля - его многие питонисты люто ненавидят, но многие оправдывают. Так вот попробовав реальный много-поточный код я как-то для себя неожиданно перебрался из лагеря первых в лагерь вторых
....
Но трудности тем и интересны в программировании, что получаешь удовольствие, когда находишь решение, которое в корне переиначивает ситуацию и либо решает, либо обходит проблему.
Так, отбросив банальное повторение кода я перешел к полному переосмыселению того как надо решать задачу общения и мониторинга состояния демона.
Одним словом я совершенно по-другому сделал эту задачу. Получилась обертка, которая транслирует команды и отлавливает изменения.
Встал вопрос с UI... а вот с десктопным UI в GO - явно не задалось - его чаще используют для постороения web-сервисов, даже web-UI обычно делают с использованим JS тулкитов.... Ну а раз у меня в питоне уже есть UI решил прикрутить его к своей GO-поделке.
И вот тут вылезли новые вопросы... Запустить процесс обертки (демона обертка сама запускать умеет) - проще простого, через stdin ему команды отдать - проще простого. Получать из stdout данные об изменениях статуса..... а вот тут затык. Слушать stdout лучше в отдельном процессе (как я думал) ведь на чтении поток будет блокироваться. Ну так и сделал... и тут у меня GTK начал сыпать корками (критическая ошибка с дампом ядра - code dumped).
Я же как находил в другом потоке данные таки начинал в GTK отрабатывать - а гтк многпоточность вообще не переваривает. Первым делом сделал чередь: поток слушатель кидает в очередь, а очередь по таймауту просматривает главный поток... велосипед с костылями еще тот- но заработало.
Однако костыльный велосипед - это не то что меня устраивает.... полез копать гугл... гуглеж ничего не дал...попробовал тостер - только один человек подписался как тот кто тоже хочет узнать ответ... гуглил дальше - нагуглил решение, сам себе на тостере ответил
.
Вот заработало все правильно - главный цикл GTK накручен смотреть сам за появлением данных в stdout (и еще stderr забирает, если включет дебаггинг индикатора).
Получился вполне
рабочий индикатор, хотя конечно тот еще бутерброд: GUI в питоне командует и слушает обертку на Go, которая "пасет" демона yandex-disk. Зато каждый язык на своем месте, питону с его GIL все-же довольно трудно следить за демоном, который сам о себе ничего не говорит (явным образом), и тут нормальная и быстрая много-поточность Go - выручает. А вот интерфейс на Go - это проблема, зато совсем не проблема для питона.
Вот теперь думаю... может запилить и эту версию индикатора на ланчпад? Правда публикация будет чуть сложнее, там ведь и сборка нужна под 64 и 32 бита (питону пофиг - он интерпритируемый, а вот go...)
А может быть уже ну ее эту 32-х битную платформу?
Да размер go-оберточки меня немного смущает... весь пакет индикатора на питионе в развернутом виде ~ 250кб (72.1 KiB в deb пакете), а одна Go-обертка весит 2,7мб (1мб в tar.gz)...
Вообщем вопросов довольно много.... попутно может таки найду на чем GUI сделать в Go... вроде как есть обертки правда полуживые почти все....
Тема: Плагины/индикаторы для индикации статуса синхронизации с Yandex-disk (Прочитано 937863 раз)
