Для индексации полезных и бесполезных разговоров

[notify_ded_bot]

а че не по классике? новое соединение в горутину?

Новое соединение = 3 горутины ) я же написал, операции чтения и записи блокируемые.

[notify_ded_bot]

Новое соединение = 3 горутины ) я же написал, операции чтения и записи блокируемые.

а че в итоге, алгоритм какой?

[notify_ded_bot]

Если нужно одновременно и читать и писать, как в случае с двунапрвленными протоколами, тут ещё всё хуже. Ну вот в этом то и вопрос.
Вроде +2 горутины не великая потеря производительности, плюс они не просто пересылают данные в канал а ещё и парсят протокол и пересылают уже полезное.
Я об этом и пишу, что без опыта сложно оценивать

[notify_ded_bot]

а че в итоге, алгоритм какой?

На одно подключение 3 го канала (чтение, запись, ошибки) две горутины для чтения/записи в сокет и одна главная, ждёт данных в каналах или внешние события и вызывает коллбэки

[notify_ded_bot]

На одно подключение 3 го канала (чтение, запись, ошибки) две горутины для чтения/записи в сокет и одна главная, ждёт данных в каналах или внешние события и вызывает коллбэки

звучит как по классике

[notify_ded_bot]

Ну классика разная. В qt один поток на всё в нём epool который просыпается по любому событию. В node тоже всё неблокируемое. Ладно… мы слишком далеко ушли от темы канала. Спасибо

[notify_ded_bot]

В го просто нельзя работать с сокетами неблокируемо, поэтому так

[notify_ded_bot]

Ну классика разная. В qt один поток на всё в нём epool который просыпается по любому событию. В node тоже всё неблокируемое. Ладно… мы слишком далеко ушли от темы канала. Спасибо

не, это ты смотришь низкоуровнево. А ты смотри повыше: libevent, libuv и т.п.

[notify_ded_bot]

в node libuv (я кстати, тоже с ним замучался)