это понятно. "не-реактивен" )

Это, опять же, можно обойти через proc_lib.

Буквально пару дней назад вспоминали об этом здесь.

Но я бы стартовал обычный процесс, а стадию "длинной" инициализации вынес в отдельный стейт конечного автомата.

Как и стадию дампов на диск.

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

ну, тут такое... дело в том, что это несколько различное поведение супервайзера может быть: одно дело актор не стартанул, и надо схлопывать весь супервайзер и остальных всех чайлдов, а другое когда он стартанул и потом упал (в фазе длинной инициализации) - тут можно попробовать его перестартовать и т.п.  Важно что это разные ситуации/политики (в акторном подходе вообще, а не в эрланге конкретно)

Падать можно с разными сообщениями.

еще можно сделать call а в гс no_reply с последующим reply. тогда не будет заблокирован. если я правильно понял, о чем вы

Нет, я о том, что супервизор будет заблокирован пока не вернется init_ack.

аа. вы про инициализацию

инициализацию можно отложенно сделать. классика же

Ну просто здесь не только инициализация отложенная, но и выход.

Поэтому логичнее выглядит FSM.

Ну, на мой взгляд. Я бы делал на FSM.

FSM хорош, но если что-то попроще на уровне gen_server,  то в init назначаете в State status:starting, запускаете через spawn_monitor процесс инициализации (c  self(), ref и параметрами инициализации), завершаете init. На все запросы во время инициализации проверяете State на status starting, сообщаете, что извини, пока не готов. Этот отдельный процесс после инициализации отдает через месседж запустившему все параметры состояния вплоть до ets (для этого есть спец функция). Зпустивший получает их через hadle_info, назначает параметры State, status назанчает в состояние working. Останавливать можно точно так же.

Но это ведь и есть FSM на gen_server.

в станадртном FSM нет инициализации в отдельном процессе

но зачем она? это дорого и непонятно, зачем

А зачем она нужна?