Кто-Нибудь знает, в го всего один поток на epoll ивент-лупе?

Вижу, что инициализируется он всего один раз, но такое чувство, что это должно быть менее перформно, если б они разделили на луп для разных ивентов
https://github.com/golang/go/blob/master/src/runtime/netpoll_epoll.go#L23

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

Там событий всегда фиксированное количество. Создание/Запись/Чтение

Как это сделано в netty, например. Правда там еще есть возможность сделать отдельный луп. Просто хотел уточнить, правильно ли я понимаю или чего-то не вижу

так в go было всегда и действительно, есть сценарии когда это может стать бутылочным горлышком, из-за чего был придуман вот такой пакет https://pkg.go.dev/github.com/valyala/fasthttp/prefork#section-readme (идея в том, чтобы запустить несколько приложений на 1 порту с GOMAXPROCS=1)

Интересно, спасибо

На один - да, но можно мультиплексить, тем более я говорил про типы ивентов, а не про fd

А как это должно работать? Вы же заранее не знаете какое событие придёт на fd

Ты всегда знаешь на уровне стандартной библиотеки, какие у тебя операции, выделяешь n-поллеров для чтение/запись, а далее регистрируешь fd в зависимости от типа

Ну-ка, это какие?

Я сразу скажу, что fasthttp не использовал, но видимо это связано с большим количеством очень мелких запросов

Высокий pps решается батчингом, а не мультиплексированием

высокая нагрузка быстрыми не связанными между собой запросами но часть насчет GOMAXPROCS — не всегда нужно =1, иногда нужно просто меньше чем дефолт, когда потоков много

помнится syscallы все равно нужно выполнять из systemstack(), зачем для этого больше потоков?

так оно мультиплексит, только между r/w эвентами, там в netpollready создается по горутине на чтение и запись из дескриптора. (если я правильно понял, орентироватся в системном коде сложно, а понимать еше сложнее)

Не совсем вас понимаю, любое исполнение на system stack, просто стек горутины паркуется и депаркуется, это же никак не связано, не?

это когда надо выжать больше перфа из сервера

Который не делает ничего?

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

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

Так ведь он не так работает же, просто запускает N процессов с gomaxprocs=1, добавляя на сокет опцию reuseport

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

https://lwn.net/Articles/542629/ Собственно основной смысл добавления reuseport расписан здесь

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

я к тому, что там будет переключение на g0

ASIO также работать может в плюсах )