Но если у воркера init/1 медленный то так лучше не делать, т.к. supervisor:start_child блокирующий.

Как альтернатива, можно сперва стартовать воркера и после этого уже отправлять его pid регистратору.
Другая опция - чтобы воркер сам себя регистрировал из init.

А воркеры реально должны перезапускаться если упали? Оно идемпотентно там всё будет?

естественно!

Да, там на каждом шагу что-то может пойти не так, предугадать все ошибки невозможно и есть чёткое понимание «начального состояния», в котором можно переродиться.

Можно init перенести в handle_continue ещё

или timeout послать, если эрланг очень старый

Господа. Мне нужно ваше одобрение или неодобрение. Совет, короче. У меня есть порт, который умеет делать всякое, но уходит в себя на несколько минут, когда выполняет задания разные. Вокруг этого порта есть gen_server обертка, который всем вопрошающим call-ами отвечает {error, busy}, если порт уже выполняет какое-то дело. Это сделано, чтобы всё не заблокировать и не плодить непонятные огромные таймауты в коде. Если порт ничего не делает, то я запускаю работу, отвечаю ok, и потом через ! шлю этому процессу результат работы, когда готово. Меня вот всё-таки такое смущает.

Я делал менеджер задач, который никогда не блокируется и проксирует запросы к пулу таких портов.

На вход ему прилетают запросы с заявленным таймаутом, а он отвечает чуть-чуть раньше, что поставить задачу на исполнение не получилось и надо еще раз

Рабочий подход. Разве что чуть более generic решение — это отдавать вместе с задачей функцию-коллбек, которая сделает что нужно.

В смысле, вместо отправки сообщения через бэнг.

Тут как раз хороший доклад от кларны: что может пойти не так с коллбеками :)

Коллбеки тоже не идеальны, конечно :) Но в это случае я бы таки положил в api коллбек.

А мне вот нипанятна. Разве call по определению не должен быть блокирующим вызовом?
Cast неблокирующий. Зачем их путать?

cast не возвращает результат, а call возвращает. А надо же как-то сообщить клиенту, что мы делать ничего не станем.

ReplyTo.

А ещё cast не проверяет, есть вообще такой процесс, насколько я помню. Т.е. просто отправка сообщения

Я делал очередь запросов внутри генсервера. Но это up to you, как говорится. Мы же не знаем всей вашей подноготной

Кстати, таймеры не нужны, если использовать время жизни в абсолютных значениях

Вот я боюсь, что очередь может забиться работой на пол дня вперёд, результатов которой никто не дождётся в итоге...