Вверх ↑
Ответов: 167
Рейтинг: 7
#1: 2024-04-10 20:35:29 ЛС | профиль | цитата
Netspirit писал(а):
Не совсем понятна роль 3-го компонента EventChannel.

Он решает проблему глобального стейта. Я бы мог сделать как в GlobalVar и Mutex - общий список на компоненты, но это бы привело, как вы и сказали, к необходимости добавления критической секции. А так, EventCnannel - весь контекст который нужен компонентам, пока только один поток одновременно работает с одним каналом событий - всё будет работать очень даже стабильно и потокобезопасно (проверил).

+ таким образом можно разделять события на категории. Разные каналы событий не будут мешать друг-другу.
В примерах есть схема, где весь список имён событий из EventChannel из точки ANames добавляется в список, и по выбору элемента списка вызывается соответствующее событие. Если этот пример расширить - могут сосуществовать другие каналы событий, которые не будут в обычных условиях доступны из оригинального канала.
Netspirit писал(а):
Потокобезопасность - да, надо внутри защитить работу со списком событий/подписчиков и флагом "уже выполняется"

Проблема этого в производительности. Блокировки не бесплатные, но было-бы неплохо в будущем добавить свойство на опциональное их включение на время отладки схемы, например...
Netspirit писал(а):
Не знаю как реализована "защита от рекурсии", но нужно убедиться что при вызове второго события (из параллельного потока), пока выполняется первое, второе не потеряется.

Реализуется именно что ингорированием события, если оно уже обрабатывается
Есть пример, где на MT потоках и двух каналах событий сделана Очередь событий - по публикации, события добавляются в MT стек, по тику таймера, по одному, забираются со стека и публикуются по имени, с данными в MT потоке.
Netspirit писал(а):
Можно добавить свойство события "что делать, если уже выполняется": пропускать или ждать.

Хмм... Это хорошая идея. Вообще "вдохновление" на создание этих компонентов у меня вообще возникло именно тогда, когда я делал другие компоненты, у которых в компоненте-контексте была единая точка, вызывающаяся в случае ошибок из самого контекста и компонентов работы с ним.
Как будет время, обязательно добавлю точку event в контекст, вызывающееся при возникновении рекурсии, и точку на ситуацию, когда у события нет подписчиков.
Netspirit писал(а):
Можно добавить методы для включения/отключения события (что ещё нарушит визуализацию...)

Вы опоздали - это уже есть Если поменять имя события в компоненте Издателя/Подписчика на пустую строку (точка doEventName), то он отпишется от события (Пустая строка - единственное некорректное имя события... Стоило Это задокументировать... Упс)
ИМХО, При правильном применении эти компоненты - золото. Можно было-бы создать сто компонентов именованных процедур, очередей, а можно просто использовать эту тройку для реализации такого поведения)
Netspirit писал(а):
Возможно, не очень удачный термин doPublish/onPublish выбран для вызова события. Вероятно, более понятно будет что-то типа doFireEvent, doCallEvent, onEvent.

Увы, с этим я наврятли уже что-то сделаю - это сломает обратную совместимость со схемами, которые уже есть у меня (и не только) и активно используют эти компоненты.
карма: 0
c, c++, lua
0
Редактировалось 7 раз(а), последний 2024-04-10 20:53:00