handle_call, мол всегда это утверждал, но не нашёл такого нигде, почему это плохо?
Так Макс здесь, задай ему вопрос адресно. 🤷♂️😉
Ну вот, может он сам ответит, или кто слышал это раньше.
Чем хороши чаты и форумы, они асинхронны, в отличие от телефонных звонков.
Ты посмотри реализацию, увидишь сколько там подводных камней. До введения алиасов была проблема, что после окончания ожидания тебе в ящик сыпали неожиданные ответы, например
Наоборот Максим говорил, что handle_call нужно почти всегда использовать, за редким исключением, потому что cast отлаживать очень проблематично и нагрузку не видно, только через очередь сообщений, но это криво
это сильно зависит от задач. В большинстве случаев call -- идеальный вариант. Что-то своё имеет смысл писать, если есть большие задержки и поточная обработка (например, кодирование видео)
Понял, проблема в плохой реализации. Но ведь уже столько новых версий вышло, проблему так и не решили?
ну ещё и решили введением алиасов. Но там всё-равно много накладных расходов. Говорю, просто посмотри реализацию и реши когда это надо а когда нет использовать
"не видно", кажется, не очень хорошо отражает, чем плохо просто что-то послать. Большой профит от call в том, что если получатель тупит, то отправитель автоматически тормозится. Т.е. чтобы перекрытая дырка на выходе из системы затормаживала всю систему, а не приводила к распуханию
Тогда call должен все время из одного и того же процесса дергаться.
в смысле из одного и того же? Если у меня 1000 процессов пишут в лог, и диск начал тупить, то call затормозит их все
Нет. Точно так же будет переполняться очередь приемного процесса, который колы обрабатывает. Точно так же, как было бы с cast.
Обсуждают сегодня