Если есть сеть объектов, которые уведомляют друг друга при помощи событий,
то как всем этим управляют? Дело в том, что если возникает одно событие,
оно при распространении генерирует вторичные события в сети объектов,
те события в свою очередь генерируют новые события и всё это размножается до невозможности.
Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если есть сеть объектов, которые уведомляют друг друга при помощи событий, ЭФ>то как всем этим управляют? Дело в том, что если возникает одно событие, ЭФ>оно при распространении генерирует вторичные события в сети объектов, ЭФ>те события в свою очередь генерируют новые события и всё это размножается до невозможности.
ЭФ>Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Когда события будут обработаны, они будут удалены. Той же сборкой мусора, ведь события — это объекты. В чем проблема?
А вообще, не очень понятно, про какие события ты говоришь. Приведи пример.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Добавляют мониторинг и 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, поэтому надо просто аккуратно всё делать.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если есть сеть объектов, которые уведомляют друг друга при помощи событий, ЭФ>то как всем этим управляют? Дело в том, что если возникает одно событие, ЭФ>оно при распространении генерирует вторичные события в сети объектов, ЭФ>те события в свою очередь генерируют новые события и всё это размножается до невозможности.
ЭФ>Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Ну, вообще говоря, возможны два варианта:
1. Граф порождения событий ацикличен — тогда бесконечный рост невозможен. Рано или поздно все события дойдут до конца своих цепочек.
2. В графе порождения событий есть циклы — тогда возникает бесконечный рост (или как минимум неубывание количества сообщений), и система затыкается.
Свойства графа — штука относительно статическая. Всё управление сводится к обнаружению и разрыванию циклов.
Обнаружение зависит от того, на чём строятся события. Может быть, у вас будет переполнение стека; может быть — out of memory, может быть — забивание очереди.
Способ разрыва цикла делается по-разному.
Для начала можно попытаться ввести классы событий, и сделать так, чтобы порождение событий обязано было менять "класс" только в одну сторону.
Ну, там — из обработчика события "файл изменился" мы можем породить событие "нужно добавить запись в лог", а вот из обработчика события "добавляем запись в лог" мы не имеем права порождать событие "файл изменился".
Иногда бывает так, что так сделать нельзя — изменения должны работать "в обе стороны". Например, в тех местах, где события делаются для синхронизации значений, обычно достаточно сделать проверку на изменение:
public void OnChangeX(int value)
{
if (x == value) return; // don't propagate a no-change!
x = value;
RaiseOnXChanged(x); // notify all the subscribers so they can reflect a new value of X.
}
Без первой строки у нас есть риск того, что кто-то из подписчиков поменяет своё значение, и сгенерирует новое OnChangeX(), свалив систему в бесконечный цикл. А при особенной удаче можно даже получить экспоненциальный рост количества необработанных сообщений.
Но такое работает в предположении однозначности устанавливаемого значения — мы легко отличаем ситуацию "уже обработано" от "ой, нет, ещё не обработано". Возможно, в цепочке будут противоречия — например, из-за округления.
Типа уменьшили ширину окна -> вложенные окна перестали влезать -> показали скролл-бар -> уменьшилась ширина окна -> одно из вложенных окон решило свернуться -> окна начали влезать -> убрали скролл-бар -> вложенное окно решило развернуться и т.п.
Для таких случаев лучше уходить от лэйаута на событиях к лэйаут менеджерам, которые видят одновременно всю "систему уравнений", и решают её без циклических согласований.
Для более общего случая, когда нет возможности отказаться от событий, и при этом мы не можем легко отличить "новое" событие от его "реплики", можно пользоваться различными способами.
Самый простой — TTL, как уже предложили. То есть после N итераций мы гарантированно прекращаем обработку события.
Достоинство — не надо выделять память под хранение предыстории. Недостаток — для маленьких N у нас есть риск не добраться до конца валидной цепочки сообщений; для больших — у нас всё ещё есть риск выполнить в N/2 (или N/3) больше работы, чем необходимо.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
S>> Свойства графа — штука относительно статическая.
ЭФ>Только граф событий не статический, и строится он поверх модели, которая тоже не статическая...
Ну, поэтому я и написал — относительно статический
Не видя конкретного примера, трудно угадать, какая доля связей известна заранее, а какая — возникает на лету.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А вот зачем было вообще вводить в язык такой синтаксис? Тем более, что функции отдельно всё равно потом по-другому добавили (Func<TResult>).
Наверное же хотели как лучше.
А если признали, что вышло плохо, наверное надо весь UI переделать по-новому?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>А вот зачем было вообще вводить в язык такой синтаксис? Тем более, что функции отдельно всё равно потом по-другому добавили (Func<TResult>). ЭФ>Наверное же хотели как лучше. ЭФ>А если признали, что вышло плохо, наверное надо весь UI переделать по-новому?
Вот сейчас не понял, о чём речь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>А вот зачем было вообще вводить в язык такой синтаксис? Тем более, что функции отдельно всё равно потом по-другому добавили (Func<TResult>). ЭФ>Наверное же хотели как лучше.
Хотели, как быстрее. События (о них же речь) были пересены в первую версию C# по мотивам Delphi и MFC. Дженерики появились лишь во второй. Т.е. Func<TResult> стало возможно гораздо позже.
ЭФ>А если признали, что вышло плохо, наверное надо весь UI переделать по-новому?
Да не так уж и плохо вышло, если смотреть на другие мертвые переделки UI.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Если есть сеть объектов, которые уведомляют друг друга при помощи событий, ЭФ>то как всем этим управляют? Дело в том, что если возникает одно событие, ЭФ>оно при распространении генерирует вторичные события в сети объектов, ЭФ>те события в свою очередь генерируют новые события и всё это размножается до невозможности
Это разветвители.
ЭФ>Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Здравствуйте, Эйнсток Файр, Вы писали: ЭФ>Если для просто объектов в памяти придумали сборку мусора, то как поступают с событиями?
Очередь сообщений всегда имеет конечный размер. Когда количество сообщений превысит максимальный размер очереди, то положить новое сообщение в очередь станет невозможным. На читающей стороне можно читать и отрабатывать все сообщения разом, накопившиеся на данный момент времени, чтобы очередь сообщений опорожнялась полностью при чтении. Всё просто, ребята.
