А кто писал сокетные фреймворки, как вы управляли пулом открытых

дескрипторов соединений? Там может прилететь, например, миллион. Наиболее быстрый способ доступа к ним всёж линейный массив, кгм...

Да mmap-ал сразу один массив под всех доступных в системе, освобождением не заморачивался

ясно, спасибо.

В Photon?

Да ну там на это есть и другие причины

Структура данных по типу таблицы, т.е. массив блоков, или нечто похожее на unrolled linked list. Так в eventcore кстати тоже сделано. Получается что к дескриптору можно обратиться напрямую по его же значению

Вот пример https://github.com/jacob1237/unio/blob/main/source/unio/primitives/table.d

спасибо большое, я посмотрю эту реализацию. Пока я пробовал malloc-овый обычный линейный массив дескрипторов, где просто start + fd * fd.sizeof без деаллокаций. Грубая реализация лупа немного превосходит по перфу хелловордный h2o, но учитывая, что во втором полноценный фреймворк, а у меня голый луп, то это незначительный отрыв вызывает много вопросов... Где-то 90% у меня недоделано и недооптимизировано. С другой стороны, там мб и сложно уже выжимать перф т.к. эти наносекунды туда-сюда на общую картину могут влиять мало, особенно когда натянется замедляющая логика навроде парсинга запроса, передачи в плагины, событийная система и т.д. и т.п. Но посмотрим... пока в процессе тестирования.

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

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

Есть ссылка на гитхаб? И как тесты запускались? У нас вроде есть неплохой бенчмарк где можно померить и сравнить перф: https://github.com/tchaloupka/httpbench

да, я это отметил выше, что нельзя просто так сразу усечь массив справа + нужно в любом случае проверять состояние каждого дескриптора в деаллоцируемом куске, что O(n), либо заюзать какие-то более быстрые способы, возможно в процессе закрытия выставляя какие-то битовые маски или ещё-что то эдакое. Но можно юзать что-то предположительное, там, возможно, если начали постоянно прилетать индексы меньше < N, то в массиве справа уже ничего не юзается или что-то около того. Потом аллокация\деаллокация больших кусков памяти тоже под вопросом в сравнении с более мелкими чанками, там, вероятно, может быть проблема найти\освободить именно большой кусок из-за дефрагментации. Но опять-таки, тут вопрос, насколько нужно серверу под нагрузкой заниматься памятью. В общем случае в этот момент любое управление памятью будет его замедлять. Можно сразу занять большую часть памяти и предаллоцировать все структуры. > Есть ссылка на гитхаб? И как тесты запускались? У нас вроде есть неплохой бенчмарк... Спасибо, но я пока на уровне очень и очень ранних экспериментов т.к. ранее с liburing не работал, настраивается оно сложно, инфы мало, да и вообще последние несколько лет бэкенда касался достаточно мало. Я сравнивал хелловорды через siege с h2o и гошным gin, поскольку нужно отталкиваться от каких-то цифр, яж не знаю, насколько быстро\медленно получается. Интереса с кем-то конкурировать никакого нет, нужен свой специализированный сервер для IoT на дишке. Архитект должен быть где-то между джавовским netty и сишным hinsightd на liburing и с Lua-шкой на борту. По факту, этот пет компенсирует перекос моего стека к графике, который дал дишный графический движок в последние несколько лет. Но бэк нельзя забывать, так что интерес сугубо образовательный и для себя. У ди много хороших фреймворков и я никоим образом не хочу с ними конкурировать, да и вообще ни с кем).

Ясно. вообще та ссылка что я дал на реализацию структуры данных, на самом деле это библиотека для построения event loop'ов, которую у меня всё руки никак не дойдут продолжить. С точки зрения интерфейса там как раз всё совместимо с io_uring (но пока доступен только epoll), так что если будет желание, то можно либо взять её за основу, либо - что еще лучше - законтрибьютить