Я могу увеличить, но канал создаётся ДО иницилизации воркеров и сервера, и я не могу знать заранее какой по хорошему размер нужен, и какой бы он ни был, мне кажется такая ситуация с блокировокй возникнуть всё равно может, а это ппц как не надёжно

А еще вопрос, в чем суть резки картинки? Ну т.е. вот вышло много много картинок, что дальше с ними?

Ничего ;D пока что ;D

ну а потом?

тогда здесь очереди нужны, а не каналы

вот такие: https://github.com/enriquebris/goconcurrentqueue#fifo

например

Ну реально ничего, я ж херней страдаю)

Не прод проект, интересно как быстро как можно нарезать кучу картинок ;D и сделать это максимально надёжно и паралельно)

окей) Задача прикольная конечно. Я просто пытался понять, будет ли тут какой профит с параллельности\конкуррентности

сонный теори крафт - а что если 2 канала - один буферезированный для воркеров (в него падают задачи на обработку) а второй буферезированный, но с запасом для пакета с данными. соответственно 2 параллельных процесса, один ставит задачи (и блокируется если буфер задач переполнен), второй нарезает картинки и складывает результат во втрой канал.

ЗЫ возможно ересь предложил

Я вот тоже думал о двух канал..... Но я ещё не пробовал реализовать, но мне кажется что это тоже не исключает полностью варианта когда система полностью встанет)

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

Ну как бы приличный профит, сейчас одна кратинка Разрешение 5200x2600 пикселей режется в один поток рекурсивно если то 13 минут! Во вторых это выжирает не мало так памяти)

Цель такая, распралелить, потому что тут это очень подходит, каждая часть картинки паралельно нарезается и каждая часть нарезаной картинки паррлельно нарезается..... и тд)

Во вторых это должно меньше жрать памяти)

Вот с очередью мне нравится идея...... Кажется действительно гораздо лучше подходит

насчет последнего утверждения чет не уверен)

Ну вообще в случае когда всё на одном инстансе через каналы и те же очереди.... то возможно, но по крайней мере GC сможет очистить память на те объекты что уже не используются из предыдущих вызовов, в случае рекурсии он так не может вроде и ждёт когда вся цепоччка рекурсии заокнчится

если картинка в 13 МП обрабатывается 13 минут в 1 поток, то явно что-то не так с самим кодом

🙄

Ну профит будет только на числе горутин соответствующем числу ядер компа имхо.
Если 4 ядра, то да, в 4 раза быстрее (теоретически) будет.
Если сделать 400 горутин, то грубо говоря на ядро по 100 горутин будут планировщиком планироваться, но вряд ли профит будет ибо резка это cpu-bound задача. Возможно будет даже медленнее из-за оверхеда.
Но это теоретически и моя прикидка. По факту надо смотреть на практике. Если задача чисто побаловаться, то даже классно.