openlang
Конкурентность и эксплуатация

Причинность в объединённых журналах почтовых ящиков

Разговор продолжается 3 ↓Посмотреть источники ↓

Если в общем логе почтового ящика стоит A1, B1, B2, A2, он говорит меньше, чем кажется.

Обычные сообщения Erlang, без приоритетного приёма, один получатель принимает все четыре события одним и тем же шаблоном. A отправляет A1, потом A2. B отправляет B1, потом B2. Сигналы от одного отправителя сохраняют его порядок, и другой гарантии порядка нет. Лог выше соблюдает порядок обоих отправителей.

Теперь пусть B1 попал в очередь на шаг раньше, перед A1. Оба порядка по-прежнему соблюдены. Значит, B1 после A1 не означает, что B действовал потому, что A1 уже обработан. B мог вообще не знать про A1.

Если B1 действительно зависит от обработки A1, эту связь должен переносить протокол. Угадывать её читателю лога не нужно. Хватит порядковых номеров по источнику и явной ссылки на событие-причину, а порядок прихода стоит читать только как порядок прихода.

Разговор продолжается 3

Следуя доводам
  1. Ссылка на ответ

    Подтверждение помогает, только если подтверждает нужное. Получить A1 и закончить обработку A1 не одно и то же. Пусть B ждёт подтверждения, что A1 применён, и кладёт этот ID в B1.

  2. Ссылка на ответ

    Идентификатор события и идентификаторы зависимостей кладём в каждую запись. Позиция строки на экране не ссылка, и перегруппировка строк ничего не должна ломать. В Odin есть ещё ловушка со стороны памяти. Динамический массив хранит свой аллокатор, даже если context.allocator потом сменился. Если записи ссылаются на текст во временном хранилище, очищать его нельзя, пока лог ещё нуждается в этом тексте. Момент очистки нужно ставить после того, как лог закончил с текстом.

  3. Ссылка на ответ

    Порядок соблюдается для пары отправитель и получатель и больше нигде, и именно это правило растягивают чаще всего. Если P отправляет Q сообщение m1, а потом просит S уведомить Q, сообщение от S может дойти до Q раньше m1. В Elixir всё так же, VM та же. Причинность не передаётся через третий процесс сама собой, так что если B1 зависит от A1, эта связь должна быть в сообщении, как вы и сказали.

Другие стороны того же вопроса

  1. Конкурентность и эксплуатация

    Если start_link вернулся, значит ли это, что кеш прогрет?

    У start_link обнадёживающее имя, но что клиент на самом деле узнал, когда вызов вернулся? Здесь init возвращает {:ok, state,…

    Ответы 3elixirgoerlang
  2. Конкурентность и эксплуатация

    При восьми местах в очереди 88 горутин всё ещё могут ждать

    Буферизованный канал ограничивает число задач внутри себя. На горутины, которые застряли на отправке, это ограничение не расп…

    Ответы 6gojavarustelixirerlang