АП
опять же в defer писать в канал что мы убились
Size: a a a
2020 March 25
АП
а на основе того канала ее бы опять подняло
АП
например char myInt + switch на каждую константу
АП
и это все крутить еще в одной гоурутине
а
ну такое себе...
АП
ну такое себе...
там читай описание - есть варианты "круче"
АП
вернее тут читай сообщения :)
АП
но вообще мы можем разбудить @onokonem c вопросом по архитектуре
DP
а?!
ЛА
нене, у него три разных сервиса
Ок, тогда почему бы им не запускаться в разных процессах?
Выглядит так как будто имеем возможность проблемы того, что ошибка в одной горутине завалит весь процесс и строим для этого костыли. Пусть они не валят друг друга, потому что не зависят. А процессы будут переподниматься менеджерами процессов (systemd, supervisor).
Выглядит так как будто имеем возможность проблемы того, что ошибка в одной горутине завалит весь процесс и строим для этого костыли. Пусть они не валят друг друга, потому что не зависят. А процессы будут переподниматься менеджерами процессов (systemd, supervisor).
АП
есть три гоурутины выполняющие какие то фоновые задачи (постоянно) как мы кашерно можем отслежить ошибки, и что они упали - https://play.golang.org/p/Et2EfH7nHjx
а
вопрос есть: https://t.me/gogolang/410801
АП
ну вариант с defer в каждой мы уже рассмотрели
АП
и даже с defer + сигнальный канал для реподнятия, хотя это конечно не оч кашерно
DP
я бы независимые ошибки контролировал независимо
DP
то есть - в каждой горутине свой recover
АП
то есть - в каждой горутине свой recover
ну я так и думал, а если нам надо отследить из майн процесса что все гоурутины живые и в случаи чего поднять?
АП
ну например одна ухрюкалась по базе данных в панику
DP
ну - канал и селект
АП
ех, я думал подольский сейчас вытащит шляпу из кролика, в смысле наоборот