PK
Таймауты на вызывающей стороне решают проблему дедлоков, а на принимающей только оптимизирует затраты. И, имхо, первое важнее чем второе. А почему бы не сделать и второе из коробки - хз, видимо не было такой задачи в эриксоне.
Size: a a a
2020 December 03
SL
ну я вот хотел бы сделать для себя такое, внутренних сообщениях все ок будет . а вот при внешних я хз как правильно
ML
ну мне просто нужна некая гарантия того, что если на обоих компах время одинаковое, то и monotonic time тоже одинаковое .. либо что-то другое одинаковое .
у тебя не просто не может быть такой гарантии, а даже сама постановка задачи несколько бессмысленная (в общем случае), потому что что любой обычный способ связи между серверами вносит такие искажения во времени, что задача синхронизации двух серверов становится бессмысленной
SL
у тебя не просто не может быть такой гарантии, а даже сама постановка задачи несколько бессмысленная (в общем случае), потому что что любой обычный способ связи между серверами вносит такие искажения во времени, что задача синхронизации двух серверов становится бессмысленной
я согласен, но мне не нужна космическая точность
ML
т.е. это как в релятивизме: нельзя говорить об одновременности событий, потому что не существует способа это померять.
ML
тогда просто по NTP настрой два сервера и успокойся
SL
ну т.е. erlang:system_time(seconds) мне поможет везде ?
ML
ну т.е. erlang:system_time(seconds) мне поможет везде ?
если тебе нужен _seconds_, то да
SL
DF
ну вообще почему то в OTP таймауты есть для отправляющей стороны в виде call .. но почему то нет для принимающей
Не очень понимаю, что значит "таймаут на принимающей стороне", поясните, плз. Процесс не может знать отправляется ли ему сообщение, для остального, типа простоя, есть handle_info
SL
Не очень понимаю, что значит "таймаут на принимающей стороне", поясните, плз. Процесс не может знать отправляется ли ему сообщение, для остального, типа простоя, есть handle_info
если в само сообщение gen_server:call поместить некий таймштамп, тогда можно узнать насколько это сообщение старо.
т.о если сообщение старше 5 секунд, то мы его можем отбросить как сообщение которое не нуждается в обработке, т.к. получатель уже не ждет ответа.
т.о если сообщение старше 5 секунд, то мы его можем отбросить как сообщение которое не нуждается в обработке, т.к. получатель уже не ждет ответа.
ММ
если в само сообщение gen_server:call поместить некий таймштамп, тогда можно узнать насколько это сообщение старо.
т.о если сообщение старше 5 секунд, то мы его можем отбросить как сообщение которое не нуждается в обработке, т.к. получатель уже не ждет ответа.
т.о если сообщение старше 5 секунд, то мы его можем отбросить как сообщение которое не нуждается в обработке, т.к. получатель уже не ждет ответа.
тогда уж лучше пусть отправляющая сторона сама к текущему времени добавляет нужное количество секунд и отправляет получившееся время. тогда принимающей достаточно будет проверить не ушла ли эта метка в прошлое. тогда размер таймаута не просочится за пределы отправляющей стороны
SL
тогда уж лучше пусть отправляющая сторона сама к текущему времени добавляет нужное количество секунд и отправляет получившееся время. тогда принимающей достаточно будет проверить не ушла ли эта метка в прошлое. тогда размер таймаута не просочится за пределы отправляющей стороны
да это все понятно, вопрос в синхронизации часов.
SL
можно ли считать erlang:system_time - нормальной функцией для выполнения этой операции
SL
всмысли одно и тоже значение я получу если часы на машинах показывают одно и тоже время ?
VS
если в само сообщение gen_server:call поместить некий таймштамп, тогда можно узнать насколько это сообщение старо.
т.о если сообщение старше 5 секунд, то мы его можем отбросить как сообщение которое не нуждается в обработке, т.к. получатель уже не ждет ответа.
т.о если сообщение старше 5 секунд, то мы его можем отбросить как сообщение которое не нуждается в обработке, т.к. получатель уже не ждет ответа.
если проблема только в этом, то можно не городить огород,
список нод вам известен, запрашивать раз в секунду их
список нод вам известен, запрашивать раз в секунду их
monotonic time
и плясать от этого времени, тут, так понимаю, +- секунда роли не играютDF
Эрланг задуман так, чтобы можно было обработать полученные сообщения позже ( например после обновления кода, который раньше этого не умел ) - так что отбрасывать "протухшие" сообщения может ориентируясь на timestamp, если разница в несколько секунд на разных машинах не значительна для задачи
DF
fs(StateTime) ->
receive
{_Msg, Time} = Msg when Time =< StateTime ->
io:format("received msg:: ~p~n", [Msg]),
fs(StateTime)
after 500 ->
fs(StateTime + 1 )
end.
start() ->
Pid = spawn(x, fs, [1]),
Pid ! { hello, 1},
Pid ! { hello, 2},
Pid ! { hello, 40},
Pid ! { hello, 10},
Pid ! { hello, 20},
Pid ! { hello, 3},
Pid ! { hello, 6},
Pid ! { hello000, 1},
Pid ! { hello999, 9},
ok.
DF
для понимая примерно
SL
Эрланг задуман так, чтобы можно было обработать полученные сообщения позже ( например после обновления кода, который раньше этого не умел ) - так что отбрасывать "протухшие" сообщения может ориентируясь на timestamp, если разница в несколько секунд на разных машинах не значительна для задачи
спасибо за код, это все давно понятно. непонято как получить одно и тоже значение времени на разных машинах.
ну наверно os:timestamp() с перемножением и сложением поможет )
ну наверно os:timestamp() с перемножением и сложением поможет )