A
Size: a a a
2020 July 23
ИИ
Мне отвечаешь - видимо со мной.
я трезвый если что
AK
пойду сам искать в чем разница между receive after и start_timer. Ато не удобно уже :)
Фиг я чего нашел, там все в нифы уходит
ИИ
Фиг я чего нашел, там все в нифы уходит
точно не в бифы?
AK
если завтра не выходной то нет
ИИ
если завтра не выходной то нет
если серьёзно - то не понятно, что ищем?
AK
как выгоднее по памяти и по процу receive after или erlang:start_timer
AK
receive after чуть красевее тем что его отменять не надо
ИИ
как выгоднее по памяти и по процу receive after или erlang:start_timer
по памяти там наверняка комариные жопки, про проц не понятно. насчет receive .. after не нарушает otp ?
AK
не нарушает, он под {reply, Reply, NewState, Timeout} от генсервера
AK
если процессов 400тыр на ноде, как орагнизовавыть таймауты в каждом из них. С учетом что в одном процессе в среднем 5 таймаутов
AK
тестить надо по любому..
ИИ
если процессов 400тыр на ноде, как орагнизовавыть таймауты в каждом из них. С учетом что в одном процессе в среднем 5 таймаутов
в генсервере наверняка итак уже ресурсы задействованы под контроль времени
VS
как выгоднее по памяти и по процу receive after или erlang:start_timer
если для
то after равносильно указанию timeout в ответе,
отдельный таймер несколько другую задачу
решает
gen процессов,то after равносильно указанию timeout в ответе,
отдельный таймер несколько другую задачу
решает
AK
если для
то after равносильно указанию timeout в ответе,
отдельный таймер несколько другую задачу
решает
gen процессов,то after равносильно указанию timeout в ответе,
отдельный таймер несколько другую задачу
решает
Это понятно. А в gen_statem именованые таймауты через start_timer идут, сильно ли это просаживает
VS
процесс таймера будет
спать в том же receive after,
так что не очень, в основном
память - байт 150 где-то
на таймер должно получиться,
спящий процесс CPU не жрет,
когда колесо системного таймера докатится, его разбудят
спать в том же receive after,
так что не очень, в основном
память - байт 150 где-то
на таймер должно получиться,
спящий процесс CPU не жрет,
когда колесо системного таймера докатится, его разбудят
SP
erlang:send_after и receive .. after под капотом тот же timer wheel используют. И помнится его основательно заоптимизировали где-то в районе OTP-21AK
значит можно и так и так и не париться, делать как удобнее