https://github.com/rpt/gen_tcp_server/blob/master/src/gen_tcp_server_handler.erl#L72

Господа, хочу вот этот дизайн обсудить. Тут супервизор запускает рабочих как temporary.
Поэтому, если мы выйдем по ветке

        {error, Reason} ->
            {stop, {gen_tcp_accept_error, Reason}, State}

у нас в руках останется живой супервизор, и минус 1 акцептящий сокет из пула. В самом плохом случае, у нас останется живой супервизор, и невозможность подключиться к нашему сокету (никто не делает accept).

в elixir каждая структура - отдельный тип, потому можно специализировать
для нее функции протокола

И кроме того, в строке 75 может не сработать supervisor:start_child, в таком случае тоже "минус 1 accept". Непонятно, как сделать тоже самое но надежнее.

        {error, Reason} ->
            {stop, {gen_tcp_accept_error, Reason}, State}

А зачем ты отключаешь воркеров от супервизора за ошибку?

Чо?

Ну, почему temporary а не permanent ?

А, потому-что когда воркер сделает accept, он работает с конкретным клиентнским сокетом дальше. В этом случае если мы его перезапустим, то просто добавим в пул аккцептящих воркеров еще один. Если произошла какая-то ошибка в клиентской сессией при работе - такова судьба, придётся её убить.

Тут паттерн такой, что воркер имеет две фазы: 1) accept  2) обслуживание клиента

Видимо нужно побольше контекста, потому что всё ещё не понятно

        {error, Reason} ->
            {stop, {gen_tcp_accept_error, Reason}, State}

ты переделываешь этот модуль?

@LamaLove
Сервер tcp соединений. Во время запуска супервизора делается gen_tcp:listen и получается сокет который принимает новые соединения. Дальше чтобы сделать сокет для каждого конкретного клиентского подключения, надо сделать gen_tcp:accept, этим занимаются воркеры. Но как только воркер успешно делает accept (пришло новое подключение), он должен вместо себя создать нового воркера, для следующего подключения, а сам заняться работой с клиентом (чтением и обработкой данных). В этой истории по хорошему, в первой половине воркер должен вести себя как permanent, а после accept как temporary.

каков предмет обсуждения? ты переделываешь или просто спрашиваешь - норм ли?

Я вижу, что не норм

Нужно как-то усовершенствовать этот дизайн

Сам паттерн описан тут:
https://learnyousomeerlang.com/buckets-of-sockets

ну да - не норм. малой кровью - можно заменить прямой вызов супервизора на другой callback куда будет передан статус. и там уж решить - запускать или нет еще одного.

У меня в голове нет ни единого приличного примера, но иметь штатный метод рантаймового полиморфизма - не лишнее. Причём, это не интерфейсы, а скорее трейты из раста.

Так вопрос не в этом. Вопрос в том, как пробросить ошибку выше. Ну решил я что надо запускать, а оно не запустилось. И об этом мы узнаем когда клиенты не смогут к нам подключиться, прочитав логи.

у вас есть супервизор, грохайте его в таком случае или ошибку пишите,
в приципе, даже не меняя код, в хандлер:handle_close

{status, _, _, Props} = sys:get_status(self()),
[Parent] = [P || P <- Props, is_pid(P)],
spawn(fn () -> exit(Pid, shutdown) end) 

как-то так

кто-нибудь проверял - что будет если enif_make_atom вызвать с одним и тем-же именем, но разными env - проблем не должно быть вроде?