Первое желание сделать это через цикл в го форме с двумя каналами (in/out). Но так как они будут выполняться в общем пуле потоков мы можем получить залипание отдельных циклов.
Можно запускать циклы в future (или вовсе оборачивать в Thread) а каналы реализовывать через общие атомы. Вот только в таком случае нам придется часть функционала core.async переписывать своими ручками.
Вот и как быть? :)
В идеале ваши "сущности" стоило бы научить самих связываться с сервером. Блокировать долгими операциями go-блок не рекомендуется. Но можно найти баланс, создавайте каналы относительно количества "сущностей", например 1 канал на 10 "сущностей". Как описано в статье, количество каналов может быть любым, никакого залипания не будет, задания которым не хватило свободных тредов будут поставлены в очередь, главное что бы эта очередь своевременно просасывалась, если не хватает тредов можно посмотреть в сторону ограничения времени опроса по таймауту, либо увеличивать количество тредов и серверные мощности.
У всех бывают опечатки, личка — отличное место куда можно сообщить о них.
Вы кроме тестов нигде кложуру не протолкнули ещё?
привет, тесты + 2 небольших сервиса в продакшене
Только документацией к core.async, по факту различий нет, go-loop и while являются просто макросами к loop.
Готовим многопоточность с core.async