История изменений
Исправление hateyoufeel, (текущая версия) :
С long-ом - переносима везде кроме винды (там не битовые массивы а списки fd). С переопределением FD_SETSIZE - переносима вообще везде (на юниксах оно будет работать как я написал, на винде не влияет т.к. там и без него нет ограничений на номер).
Кто на венде пользуется select() и зачем? Гоните его! Насмехайтесь над ним! На венде есть куда более производительные и удобные API.
Если у тебя каким-то сраным хером номера fd будут в районе миллиарда, ты будешь сотни метров выделять просто под select()?
Не будут, ядро не позволит. В ядре для списка fd процесса тоже массив и весьма ограниченной длины (и ещё больше ограниченной через sysctl вроде). А если ты даже пересоберёшь ядро чтобы оно разрешало такие fd, то способов сделать такой номер ровно два: либо открыть миллиард дескрипторов одновременно, либо специально сделать dup2() на этот номер. Потому как автоматическое выделение fd (везде, кроме винды, там это вообще не индексы) делается строго по очереди (самый маленький из свободных).
Это где-то гарантируется? Нет? Ну и в лес. Ты мне тут сам затираешь про переносимость, а потом рассказываешь про непереносимые костыли, которые могут сломаться буквально завтра.
То, что там массив, это всего лишь незначительная деталь реализации. Завтра там будет дерево, а fd будут начинаться сразу с миллиарда (после 0, 1 и 2).
Проблемы у селекта две:
Нет, проблем у select() куда больше.
Зато у него есть два плюса:
- его все знают
Кто все? Пачка 70-летних маразматиков, которые застали select(), но не застали даже poll()? Последний, кстати, тоже входит в POSIX.
- это единственный полностью кроссплатформенный способ опроса
Он не кросс-платформенный. В той же macos select() постоянно сломан, потому что на него там срать хотели. На венде твои выкрутасы с FD_SETSIZE тоже будут вертеть на одном месте. Те же перцы из curl используют poll(). И что-то мне подсказывает, они про кросс-платформенность знают больше чем ты.
А так, если нам заранее известна ОС, то наверно для простых применений удобнее poll (сам его использую для них) а для нагруженных - kqueue или epoll, да.
Или можно просто не быть ушлёпком и взять libuv какой-нибудь, где всё уже нормально сделано за нас. Потому что ты всё равно его переизобретаешь в каждом втором своём проекте заново.
Так и тянет сунуть в glibc коммит с вот таким:
Да нет, достаточно вырезать ifndef вокруг define который туда вставили специально чтоб можно было переопределять:
#ifndef FD_SETSIZE #define FD_SETSIZE 1024 #endif
Нет, не достаточно. В моём случае код сломается при сборке. В твоём – просто насрёт в память. Я понимаю, что срать в память – это любовь каждого сишника, но пора бы уже приучаться к горшку. Ты большой мальчик, я в тебя верю!
Исходная версия hateyoufeel, :
С long-ом - переносима везде кроме винды (там не битовые массивы а списки fd). С переопределением FD_SETSIZE - переносима вообще везде (на юниксах оно будет работать как я написал, на винде не влияет т.к. там и без него нет ограничений на номер).
Кто на венде пользуется select() и зачем? Гоните его! Насмехайтесь над ним! На венде есть куда более производительные и удобные API.
Если у тебя каким-то сраным хером номера fd будут в районе миллиарда, ты будешь сотни метров выделять просто под select()?
Не будут, ядро не позволит. В ядре для списка fd процесса тоже массив и весьма ограниченной длины (и ещё больше ограниченной через sysctl вроде). А если ты даже пересоберёшь ядро чтобы оно разрешало такие fd, то способов сделать такой номер ровно два: либо открыть миллиард дескрипторов одновременно, либо специально сделать dup2() на этот номер. Потому как автоматическое выделение fd (везде, кроме винды, там это вообще не индексы) делается строго по очереди (самый маленький из свободных).
Это где-то гарантируется? Нет? Ну и в лес. Ты мне тут сам затираешь про переносимость, а потом рассказываешь про непереносимые костыли, которые могут сломаться буквально завтра.
То, что там массив, в чём я кстати очень сомневаюсь, это всего лишь незначительная деталь реализации. Завтра там будет дерево, а fd будут начинаться сразу с миллиарда (после 0, 1 и 2).
Проблемы у селекта две:
Нет, проблем у select() куда больше.
Зато у него есть два плюса:
- его все знают
Кто все? Пачка 70-летних маразматиков, которые застали select(), но не застали даже poll()? Последний, кстати, тоже входит в POSIX.
- это единственный полностью кроссплатформенный способ опроса
Он не кросс-платформенный. В той же macos select() постоянно сломан, потому что на него там срать хотели. На венде твои выкрутасы с FD_SETSIZE тоже будут вертеть на одном месте. Те же перцы из curl используют poll(). И что-то мне подсказывает, они про кросс-платформенность знают больше чем ты.
А так, если нам заранее известна ОС, то наверно для простых применений удобнее poll (сам его использую для них) а для нагруженных - kqueue или epoll, да.
Или можно просто не быть ушлёпком и взять libuv какой-нибудь, где всё уже нормально сделано за нас. Потому что ты всё равно его переизобретаешь в каждом втором своём проекте заново.
Так и тянет сунуть в glibc коммит с вот таким:
Да нет, достаточно вырезать ifndef вокруг define который туда вставили специально чтоб можно было переопределять:
#ifndef FD_SETSIZE #define FD_SETSIZE 1024 #endif
Нет, не достаточно. В моём случае код сломается при сборке. В твоём – просто насрёт в память. Я понимаю, что срать в память – это любовь каждого сишника, но пора бы уже приучаться к горшку. Ты большой мальчик, я в тебя верю!