Если есть сеть объектов, которые уведомляют друг друга при помощи событий,
то как всем этим управляют? Дело в том, что если возникает одно событие,
оно при распространении генерирует вторичные события в сети объектов,
те события в свою очередь генерируют новые события и всё это размножается до невозможности.
Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если есть сеть объектов, которые уведомляют друг друга при помощи событий, ЭФ>то как всем этим управляют? Дело в том, что если возникает одно событие, ЭФ>оно при распространении генерирует вторичные события в сети объектов, ЭФ>те события в свою очередь генерируют новые события и всё это размножается до невозможности.
ЭФ>Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Когда события будут обработаны, они будут удалены. Той же сборкой мусора, ведь события — это объекты. В чем проблема?
А вообще, не очень понятно, про какие события ты говоришь. Приведи пример.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Добавляют мониторинг и storm-control
Кидать события в общий пул. Если на событие нет подписчика — удалять. Если есть подписчики — каждому рассылать. У обработчика можно возвращать флаг, кто именно удаляет событие — или сам обработчик или тот, кто вызывает обработчики.
H> Кидать события в общий пул. Если на событие нет подписчика — удалять. Если есть подписчики — каждому рассылать. У обработчика можно возвращать флаг, кто именно удаляет событие — или сам обработчик или тот, кто вызывает обработчики.
Проблема не в том, чтобы удалять события, а в том, что:
1) они, бывает, образуют циклы.
2) этих событий слобопредсказуемое количество.
H> в общий пул.
Кстати, в для кого общий? Всех объектов программного комплекса (как блокчейн)? машины? процесса? нити? Или у каждого объекта пул общий для всех событий предназначенных для этого объекта?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Или вот, допустим, что мониторинг обнаружил возникновение шторма, то что делать?
Он просто выключает канал на время, для предотвращения дальнейшего усиления.
ЭФ>Какие правила вводить и проверять, чтобы такое не повторялось?
Правильно проектировать, что бы такое не возникало. Или же предусматривать гасящие механизмы.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>1) они, бывает, образуют циклы.
Пускай образуют. Все равно событие само по себе ничего не значит. Важна лишь их обработка.
ЭФ>2) этих событий слобопредсказуемое количество.
А зачем предсказывать их количество? Или их может быть так много, что оперативки не хватит?
ЭФ>Кстати, в для кого общий? Всех объектов программного комплекса (как блокчейн)? машины? процесса? нити?
Общий для менеджера событий. Только он про пул должен знать. Обработчики и подписанты на события ничего про пул знать не должны
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Ну вот я и спрашиваю — как это делать, как проектировать правильно (и чем это правильное проектирование отличается от неправильного).
Используйте инженерные подходы, предварительные расчеты, моделирование, оперативный контроль
ЭФ>> Ну вот я и спрашиваю — как это делать, как проектировать правильно (и чем это правильное проектирование отличается от неправильного). _> Используйте инженерные подходы
Хотелось бы больше конкретики. Вот сейчас модно всё асинхронное, например асинхронные методы.
Мне бы какой туториал про асихронные события для C#.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если есть сеть объектов, которые уведомляют друг друга при помощи событий, ЭФ>то как всем этим управляют? Дело в том, что если возникает одно событие, ЭФ>оно при распространении генерирует вторичные события в сети объектов, ЭФ>те события в свою очередь генерируют новые события и всё это размножается до невозможности.
У объектов есть какие-то состояния и четко формализованные правила перехода между ними? Начни с добавления машины состояний, посмотри должны ли быть такие петли как ты пишешь в принципе. Вполне может быть что ты на этой стадии уже уберёшь свои бесконечно размножающиеся события.
Если описанная ситуация часть протокола и всё это безобразие соответствует дизайну, то начни с простейшего решения — добавь в каждому сообщению TTL. При прохождении через каждый из узлов уменьшай TTL и в конце концов просто "убивай" событие.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Проблема не в том, чтобы удалять события, а в том, что: ЭФ>1) они, бывает, образуют циклы.
Посмотреть, как оно в Qt, например. Там теоретически тоже могут циклы возникать. Например, задаём для QEdit'а текст. У этого QEdit'а есть обработчик события OnTextChanged, который проверяет установленное значение, и задаёт для QEdit'а новое. Если ничего не делать, то вот тебе и цикл. В кути не ковырял, но в винде есть события, которые можно посылать контролам, и они не генерят ничего нового. Типа: событие ввода пользователя — генерится OnEditTextChanged, отсылается подписчикам, они устанавливают новое значение способом, не порождающим новые события
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
У объекта события держать атомарный счетчик, который говорит сколько уровней прошло от момента первичной генерации события. Также у объекта события добавить флаг позволять или нет генерировать новые события. Возможно может помочь у объекта события добавить объект родительского события, это позволит отследить циклы, причем можно это сделать достаточно оптимально.
Но вообще, слабо представляю ситуацию, когда реально события идут как снежный ком и действительно вероятны циклы.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Дело в том, что если возникает одно событие, ЭФ>оно при распространении генерирует вторичные события в сети объектов, ЭФ>те события в свою очередь генерируют новые события и всё это размножается до невозможности.
В обработчике события на входе можно проверить и захватить лок — признак, что мы сейчас в процессе обработки этого события.
Если в процессе дальнейшей обработки события мы опять вернёмся в текущий обработчик, то проверка лока нам укажет, что это повторный вход.
Типа такого:
private int _lock;
public bool TryProcessEvent(TEvent ev)
{
if (Interlocked.Exchange(ref _lock, 1) != 0)
return false;
try
{
UncheckedProcessEvent(ev);
}
finally
{
_lock = 0;
}
return true;
}
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>>> Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями? _>> Добавляют мониторинг и storm-control
ЭФ>А что конкретно делает storm-control? ЭФ>Если он часть событий просто выбросить в мусор, то логика получится некорректная.
ЭФ>Или вот, допустим, что мониторинг обнаружил возникновение шторма, то что делать? ЭФ>Какие правила вводить и проверять, чтобы такое не повторялось?
Про события я точно не знаю, с таким не сталкивался. Но обычно — да, выкидывают лишние объекты. Да, логика получится некорректная. Но если ничего не делать, то система просто зависнет. И это ещё хуже. А чтобы логика не получалась некорректная, тут уже на уровне алгоритмов и прочего делают, например повтор и тд.
Простой пример — протокол IP. Если роутер получает больше пакетов, чем успевает передать, то он отбрасывает входные пакеты. Сколько-то пакетов он может накопить во внутреннем буфере, чтобы скомпенсировать кратковременный пик трафика, но если этот пик не кратковременный, то эта стратегия только отсрочит тот момент, когда таки придётся отбрасывать входящие пакеты. А протоколы уровня TCP уже проектируются исходя из этого свойства, например когда они видят, что IP-пакеты начинают пропадать, они посылают их заново и при этом уменьшают скорость соединения.
Я не хочу кустарные примеры. Я хочу всесторонне проработанную технологию.
До широкого внедрения сборки мусора набось так же говорили, мол в С++ есть деструкторы и RAII, поэтому надо просто аккуратно всё делать.
