Использовать неблокирующиеся сокеты, работая с ними в рамках одного треда.

Дополнительные треды использовать не допускается. Соответственно, никаких блокирующихся вызовов (кроме вызова селектора) не допускается.

С такой формулировкой как думаете можно использовать горутины для хэндла tcp запросов?

for { conn, err := listener.Accept() go handleConnection(conn) } Имею ли я право с таким тз писать так или надо как-то по другому? Если по другому то как

в рамках одного треда? GOMAXPROCS=1

мб в go есть условный poll? select вроде похож, но как будто он не подходит

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

В принципе можно, но под ДоС'ом оно ляжет по out of memory. Я б поизвращался и сделал, например, канал коннектов, из которых читает заранее известное (или изменяющееся в заданных пределах) количество рутин

буферы сокетов в ядре занимают куда больше памяти, чем горутина

увидел вроде есть poll в постгресе Может он мне подойдет? Делать accept, класть и слушать файловые дескрипторы?

Это какое-то тестовое задание? Если да, то go там явно не подразумевался в качестве языка, на котором будет решение. Потому что почти всегда хватает горутины на соединение. Не хватает, если соединений планируется ну очень много, порядка миллиона. Вот там да, нужно думать над неблокирующим вводом-выводом (для чего есть специальные библиотеки)

это немножечко чушь мы все читали ту мейлрушную статью, но не все внимательно, видимо если у вас много (1М+) соединений, и на них ничего не происходит большую часть времени - вы можете что-то наэкономить, сократив количество горутин но если у вас там трафик - горутин придется держать столько, сколько и соединений, потому что чудес не бывает

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

Морально попадает

0_0

а как морально починить?

буф канал (не читал тред)

go, так-то, сразу запускает дополнительные треды, больше одного go запускает дополнительные треды для блокирующих сисколов так что - никак

тут вопрос можно ли считать файберы тредами?

о каких файберах речь?

А как они там предлагают экономить? Явно создавать сетевой стек, начиная с еполла, а не использовать встроенный?

тех, которыми подразумевались быть горутины, но немного не совсем стали

полл, кстати, так же болеет проблемой 10к

а у него под капотом системный вызов poll?

у кого?

у гошного полла

если они не намудрили с неймингом, то теоретически - да

ага и по событиям на epoll запускать горутину для обработки

а?!

это ограничение гошного поллера, пока сокет ожидает ивентов от поллера - его буфер чтения простаивает, ожидают миллион сокетов - миллион буферов простаивают. хотя одновременно прилетят не больше сотни-тысячи ивентов, можно было бы использовать меньшее количество буферов. я как-то на это оптимизировал чтение, но потом в рантайм добавили поддержку splice на копирование из сокета в сокет без буферов в юзерспейсе и это решило эти проблемы

китайцы жгут в этом направлении https://github.com/panjf2000/gnet