Как стать автором
Обновить

Комментарии 6

По-моему тут проблема не с gen_server, а с recieve ... msg

Вот в доке даже пример есть, как надо

receive do

message when Mint.HTTP.is_connection_message(conn, message) -> ...

Насколько помню Erlang это не поможет т.к. уже вычитали сообщение из почтового ящика процесса… Тут вроде как этот код по хорошему надо выносить в handle_info дополнительно, и не делать receive а ждать что сообщение и так туда придет

Да вроде нет

1> self() ! '4', receive M when is_integer(M)-> M+1 after 100 -> receive N -> {common, N} end end.     
{common,'4'}
2> self() ! 4, receive M when is_integer(M)-> M+1 after 100 -> receive N -> {common, N} end end.  
5
Спасибо, что упомянули про этот метод.

Он и правда делает вложенный receive loop возможным с некоторыми оговорками. В общем, тут есть несколько моментов, которые я хотел бы упомянуть:
— во-первых, `is_connection_message` появился только год с небольшим назад и не был доступен ни разработчикам tesla, писавшим минтовский адаптер, ни нам на момент описываемых событий;
— во-вторых, в том самом примере из доки минта, есть клоз с other, который прекрасно обработает сообщения внешнего receive loop'а;

Но даже если предположить, что вложенный receive loop не имеет other клоза, это все ещё блокирующий вызов и может, например, крашнуть процесс генсервера по таймауту GenServer.call'а.

В любом случае мой посыл — быть внимательными к тому коду, что выполняется в коллбеках.

Проблема в том, что разработчик функции, содержащей receive loop, не может контролировать то, как её будут использовать. Тогда нужно говорить скорее о том, что в принципе использование receive loop в потоке, который не контролируешь - плохая идея. А уж если по какой-то причине используешь, то лови только те сообщения, которые нужны

Полностью согласен ​
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.