среда, 12 января 2022 г.

[prog.c++] Очень приятно. Да и не пустяк это вовсе

Простите, что опять про SObjectizer, но таки чертовки приятно:

Один из тех моментов в которые осознаешь, что все было не зря.

Кстати говоря, ребята, которые реализовали ту систему управления сценическим оборудованием, не особо афишируют для какого именно театра она была сделана. Мне же "по блату" намекнули и я до сих пор в нехилом апупении пребываю :) Вот даже и предполагать не мог где в итоге окажется частичка моих трудов.

С SObjectizer-ом вообще есть два примечательных момента, к которым я до сих пор не знаю как относиться.

Первый момент связан с тем, что мы, разработчики SObjectizer-а, практически не знаем кто, где, как и для чего SObjectizer применяет. Информация до нас если и долетает, то случайно и, что называется, задним числом. Что, в принципе, понятно: лицензия пермиссивная, можно брать и использовать, ни у кого разрешения спрашивать не нужно, ставить кого-то в известно необязательно.

Второй момент связан с тем, что у нас редко спрашивают совета о том, как что-то сделать с помощью SObjectizer-а. Бывает человек задаст вопрос, затем через месяца два еще один вопрос. А еще через полгода спросит какую-то мелочь и скажет, что у них уже несколько месяцев как софтина на базе SObjectizer-а в эксплуатации находится.

Исключение пока что было только одно: более-менее приличное количество вопросов касательно SObjectizer-а назадавал один разработчик из Италии. А вот наши суровые парни, походу, сами во всем разбираются :)

Особенно сильно доставляют случаи, когда на меня выходят с вопросом из категории "нам вот такого вот не хватало, мы переделали кой-чего в потрохах SObjectizer-а и теперь хотим еще попробовать извратиться вот так вот, как думаете, получится?"

вторник, 11 января 2022 г.

[prog.c++] Послесловие к релизу SObjectizer-5.7.3 и so5extra-1.5.0. С оглядкой на 20-летие проекта SObjectizer

Давеча удалось выкатить новые релизы для SObjectizer-а и сопутствующего ему проекта so5extra. Не могу сказать, что релизы знаковые, новых фич не так уж много. Но радует сам факт того, все-таки получилось обновить SO-5/so5extra (после безнадеги 2020-го и, особенно, 2021-го, годов).

Подробную информацию о том, что вошло в SO-5.7.3 можно найти здесь, а о том, что вошло в so5extra-1.5.0 -- здесь. Ничего революционного. Просто реализуются хотелки, которые накапливаются по мере использования SObjectizer разными людьми в разных условиях.

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

[prog.c++] В каком направлении можно было бы развивать SObjectizer, если бы представилась такая возможность

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


Например, одно из направлений -- это повышение уровня гарантий, которые SObjectizer предоставляет разработчикам. В частности, более строгое и формальное определение моментов и условий, в которых SObjectizer вынужден прерывать работу приложения через std::abort/std::terminate. А также проработка вариантов, которые бы позволили SObjectizer-у уменьшить количество случаев обращения к std::abort/std::terminate.

К сожалению, текущая реализация SObjectizer не всегда может восстановиться после ошибок и лучшее, что может сделать SObjectizer, дабы не оказаться в непонятно каком состоянии -- это вызвать std::abort (или std::terminate).

Когда SObjectizer применяется на server-side, это неприятно, но не сильно критично. Но вот при разработке GUI приложений такое поведение снижает коэффициент спокойного сна гораздо сильнее.

Пока не удавалось уделить достаточного внимания этому аспекту. Проработка подобных моментов требует времени и скрупулезности, а видимого эффекта в виде набора понятных и полезных фич не дает.


Другое возможное направление -- это попытка адаптации SObjectizer-а к условиям, в которых требуется большая предсказуемость кода. Например, сейчас в SObjectizer активно используется динамическая память. Так, очереди заявок у диспетчеров -- это растущие по мере необходимости контейнеры, которые динамически работают с памятью. И на это пока никак нельзя повлиять. Т.е. пока нет возможности сделать диспетчер с преаллоцированной очередью заявок фиксированного размера.

В этом направлении так же было бы интересно поработать. У меня нет желания адаптировать SObjectizer к задачам жесткого реального времени, да и сам по себе SObjectizer-5 к этому вряд ли пригоден. Но даже вне задач реального времени предсказуемый расход ресурсов может быть полезен. Например, в приложении возникает bad_alloc и нужно откатиться в какое-то безопасное состояние. При таком откате успешность других new, даже для маленьких по размеру объектов, не гарантируется, поэтому хотелось бы иметь возможность обмениваться сообщениями между какой-то группой агентов без скрытых где-то в потрохах new.


В общем, можно сказать так: SObjectizer уже оброс достаточно большой функциональностью, теперь акцент следовало бы сместить в сторону большей кастомизируемости и дальнейшему повышению надежности и предсказуемости.