YZ
Try catch латает последствия пост фактум, а не решает проблему
Size: a a a
2018 November 08
Е
он решает не проблему, а исправляет кривой дизайн
Е
полагаю, его не исправляют из-за слишком серьезного breacking change
DR
after Timeout ->
erlang:demonitor(Mref, [flush]),
exit(timeout)
erlang:demonitor(Mref, [flush]),
exit(timeout)
DR
А её создаёт сам call
DR
Проблема искуственная!
DR
{'DOWN', Mref, _, _, Reason} ->
exit(Reason)
exit(Reason)
YZ
Решение проблемы, это когда к воркеру, завершившемуся штатным образом, никто и не пытается делать запросы.
DR
Вот вместо exit- возвращать ошибку и нет проблемы.
DR
Ты не избавишься от race condition
Е
можно запилить свой GenServer, где обернуть call в try/catch :) и путать этим новых членов команды.
DR
Таким образом никогда.
YZ
Совсем избавиться от race condition нельзя, можно управлять вероятностью
ŹR
Dmitry Russ (Aleksandrov)
after Timeout ->
erlang:demonitor(Mref, [flush]),
exit(timeout)
erlang:demonitor(Mref, [flush]),
exit(timeout)
Ну вот, я был не прав
ŹR
Надо почитать код генсервера
DR
Приходит левый процесс, которому только сейчас нужно знать, даже если он поставит монитор и проверит, что не завершилось - обратиться к процессу - а тот до запроса умрёт, всё равно будет race condition.
DR
А вместе с gen_server-ом будет 2 монитора.
Е
try/catch сводит вероятность race condition к вероятности бага в эликсире или BEAM и сбоя железа
YZ
Проблема вашего подхода в том, что он не различает воркера, завершившегося штатно, от воркера, завершившегося аварийно.
DR
Yuri Zhloba
Совсем избавиться от race condition нельзя, можно управлять вероятностью
Можно try/catch избавляет от race condition-а.