если кеш в ets — я воткнул бы в спавн :)
только я все еще нуб)
мб кто решение получше предложит

У меня кеш днс отлично себя в етс чувствует

https://erlang.org/doc/design_principles/spec_proc.html#special-processes и отп и можешь написать сам функционал task в том объеме, который нужен

Но это уже 5 строчек как минимум. И одна из них - spawn

Если результат записи в кеш неважен, то можно просто заспаунить процесс с синхронным коллом, этот процесс проживет максимум 5 секунд (если там дефолтный gen_server:call). Чего тут изобретать вундервафлю, сделай чтобы работало. Я вообще не вижу где тут может что-то сломаться.

Если же результат записи важен, тебе всё равно нужно будет ждать результата.

Одна из них spawn_monitor

Во блин, я не знал про такую. Упустил - никогда не спауню просто)

а простой спавн сколько секунд живет после выполнения последней строчки?
разве больше 1 секунды?

всегда думал - 1 секунду или еще меньше

Умирает тут же.

о, значит все ок)

proc_lib:spawn + monitor + еще может что по-мелочи. (менять pid owner надо )

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

в постгре годами фичи проталкивают и ничего

Это не ложится на отп с супервизорами. Вообще такая тема через simple one for one делается. Но не в две строчки.

кстати, вопрос насчет телнета и той части эрланга, которую я все еще не полностью понял, не догнал - не доучил...

с одной стороны - в телнета по-умолчания 10 секунд на одну команду,
включая и те функции otp, которые можно напрямую с телнет-железякой использовать, без отдельного драйвера - коннектора —
это вроде как стандарт в телнета

с другой стороны - вот я нашел на гитхабе драйвер-коннектор, форкнул, выбросил зависимость
https://github.com/221V/telnet/blob/master/src/plugins/olt_zte_telnet.erl
(это рабочий модуль для zte железяки)

да вот не совсем доганяю два момента —

1 — в каком порядке ездит ответ телнета между актерами —
после ответа от железяки и перед ответом этого драйвера-коннектора —
так я пока в параллельное программирование не-осень — пока я только в фп-декларативное ок

там вроде есть 1 актер, который соединение, и передает команды-ответы туда-отбратно(на-с железяку(и) ) — или это два отдельные - не суть,
+ там на каждую команду создается отдельный актор (если я правильно работу драйвера понял) —
вопрос — а нафига так сделали??
телнет ведь тупо последовательный..

и как это переписать на последовательное вместо параллельного кода (запилить тру-последовательное — вместо псевдо-параллельной имитации последовательного исполнения) ?

если пилить такой же драйвер к телнет-железяке с нуля только с otp — я так понимаю, получится примерно такой же драйвер-коннектор...
значит, проще пофиксать то, что уже есть

итого прошу подсказки — на какие строчки с этих двух модулей
src/plugins/olt_zte_telnet.erl
src/telnet_client.erl
надо посидеть-помедитировать, чтобы понять - и дальше самому эту вакханалию исправить?

чтобы было получше, и работало получше, чем есть сейчас —

там сейчас еще ответ телнета - станички 3й и дальше (если в команды телнета много страниц) — попадают в аккумулятор с мусорными символами.. 🙈
и что-то мне кажется, что это в драйвере ошибка есть, не в железяке.. ибо разные железяки - а бага та же

в proc_lib ложится, почему нет? ну или в отдельную либу task, есть же всякие async_call в rpc

этож несколько функций посути

кстати, может ты rpc:async_call|yield и обойдешься

вот такое...

и еще эти мусорные \b могут быть и посредине вперемешку((