Если представится возможность продолжить работу над 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 уже оброс достаточно большой функциональностью, теперь акцент следовало бы сместить в сторону большей кастомизируемости и дальнейшему повышению надежности и предсказуемости.
Комментариев нет:
Отправить комментарий