Комментарии 11
Перед мной стоит задача запустить несколько потоков слежения за некими сущностями в сети. Сущностей может быть много(10,20,100). А частота опроса не должна сильно плавать. При всем при этом мы хотим этим сущностям посылать команды и контролировать результат выполнения команды.
Первое желание сделать это через цикл в го форме с двумя каналами (in/out). Но так как они будут выполняться в общем пуле потоков мы можем получить залипание отдельных циклов.
Можно запускать циклы в future (или вовсе оборачивать в Thread) а каналы реализовывать через общие атомы. Вот только в таком случае нам придется часть функционала core.async переписывать своими ручками.
Вот и как быть? :)

В идеале ваши "сущности" стоило бы научить самих связываться с сервером. Блокировать долгими операциями go-блок не рекомендуется. Но можно найти баланс, создавайте каналы относительно количества "сущностей", например 1 канал на 10 "сущностей". Как описано в статье, количество каналов может быть любым, никакого залипания не будет, задания которым не хватило свободных тредов будут поставлены в очередь, главное что бы эта очередь своевременно просасывалась, если не хватает тредов можно посмотреть в сторону ограничения времени опроса по таймауту, либо увеличивать количество тредов и серверные мощности.

Смотрите в сторону actor model. Okku или что там в Clojure. С CSP это ад будет, оно только для простеньких вещей годится.
В примере №3 фраза «callback hall» звучит как попытка перестать бороться с нерешаемой проблемой и начать идолизировать её

У всех бывают опечатки, личка — отличное место куда можно сообщить о них.

Ого, привет, Олег))
Вы кроме тестов нигде кложуру не протолкнули ещё?
Чем обосновано в данных примерах использование цикла (go-loop []… (recur)) вместо (go (while true ...))?

Только документацией к core.async, по факту различий нет, go-loop и while являются просто макросами к loop.

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