LINUX.ORG.RU

История изменений

Исправление firkax, (текущая версия) :

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

Если у тебя каким-то сраным хером номера fd будут в районе миллиарда, ты будешь сотни метров выделять просто под select()?

Не будут, ядро не позволит. В ядре для списка fd процесса тоже массив и весьма ограниченной длины (и ещё больше ограниченной через sysctl вроде). А если ты даже пересоберёшь ядро чтобы оно разрешало такие fd, то способов сделать такой номер ровно два: либо открыть миллиард дескрипторов одновременно, либо специально сделать dup2() на этот номер. Потому как автоматическое выделение fd (везде, кроме винды, там это вообще не индексы) делается строго по очереди (самый маленький из свободных).

Проблемы у селекта две:

  1. действительно, выделять ради одного дескриптора с номером 10000 (это вполне реально уже в отличие от твоего миллиарда) целый массив в 2250 байт, а затем в ядре в цикле искать в нём этот единственный единичный бит - как-то нехорошо, но эта проблема неактуальна если прога использует всего несколько дескрипторов.

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

Зато у него есть два плюса:

  1. его все знают

  2. это единственный полностью кроссплатформенный способ опроса

А так, если нам заранее известна ОС, то наверно для простых применений удобнее poll (сам его использую для них) а для нагруженных - kqueue или epoll, да.

Так и тянет сунуть в glibc коммит с вот таким:

Да нет, достаточно вырезать ifndef вокруг define который туда вставили специально чтоб можно было переопределять:

#ifndef FD_SETSIZE
#define FD_SETSIZE 1024
#endif

Хм, походу в glibc таки сделали почти как ты хочешь, они затирают кастомные #define своими, а из-за каких-то флагов компилятора это переопределение define (без undef!) не пишет никаких варнингов.

Ну значит ты частично прав - в современном Linux просто переопределить FD_SETSIZE не получится, придётся объявлять свой альтернативный fd_set и свою альтернативную константу для его размера. Но стеку все равно ничего не угрожает.

Исправление firkax, :

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

Если у тебя каким-то сраным хером номера fd будут в районе миллиарда, ты будешь сотни метров выделять просто под select()?

Не будут, ядро не позволит. В ядре для списка fd процесса тоже массив и весьма ограниченной длины (и ещё больше ограниченной через sysctl вроде). А если ты даже пересоберёшь ядро чтобы оно разрешало такие fd, то способов сделать такой номер ровно два: либо открыть миллиард дескрипторов одновременно, либо специально сделать dup2() на этот номер. Потому как автоматическое выделение fd (везде, кроме винды, там это вообще не индексы) делается строго по очереди (самый маленький из свободных).

Проблемы у селекта две:

  1. действительно, выделять ради одного дескриптора с номером 10000 (это вполне реально уже в отличие от твоего миллиарда) целый массив в 2250 байт, а затем в ядре в цикле искать в нём этот единственный единичный бит - как-то нехорошо, но эта проблема неактуальна если прога использует всего несколько дескрипторов.

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

Зато у него есть два плюса:

  1. его все знают

  2. это единственный полностью кроссплатформенный способ опроса

А так, если нам заранее известна ОС, то наверно для простых применений удобнее poll (сам его использую для них) а для нагруженных - kqueue или epoll, да.

Так и тянет сунуть в glibc коммит с вот таким:

Да нет, достаточно вырезать ifndef вокруг define который туда вставили специально чтоб можно было переопределять:

#ifndef FD_SETSIZE
#define FD_SETSIZE 1024
#endif

Исправление firkax, :

С long-ом - переносима везде кроме винды (там не битовые массивы а списки fd). С переопределением FD_SETSIZE - переносима вообще везде (на юниксах оно будет работать как я написал, на винде не влияет т.к. там и без него нет ограничений на номер).

Если у тебя каким-то сраным хером номера fd будут в районе миллиарда, ты будешь сотни метров выделять просто под select()?

Не будут, ядро не позволит. В ядре для списка fd процесса тоже массив и весьма ограниченной длины (и ещё больше ограниченной через sysctl вроде). А если ты даже пересоберёшь ядро чтобы оно разрешало такие fd, то способов сделать такой номер ровно два: либо открыть миллиард дескрипторов одновременно, либо специально сделать dup2() на этот номер. Потому как автоматическое выделение fd (везде, кроме винды, там это вообще не индексы) делается строго по очереди (самый маленький из свободных).

Проблемы у селекта две:

  1. действительно, выделять ради одного дескриптора с номером 10000 (это вполне реально уже в отличие от твоего миллиарда) целый массив в 2250 байт, а затем в ядре в цикле искать в нём этот единственный единичный бит - как-то нехорошо, но эта проблема неактуальна если прога использует всего несколько дескрипторов.

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

Зато у него есть два плюса:

  1. его все знают

  2. это единственный полностью кроссплатформенный способ опроса

А так, если нам заранее известна ОС, то наверно для простых применений удобнее poll (сам его использую для них) а для нагруженных - kqueue или epoll, да.

Так и тянет сунуть в glibc коммит с вот таким:

Да нет, достаточно вырезать ifndef вокруг define который туда вставили специально чтоб можно было переопределять:

#ifndef FD_SETSIZE
#define FD_SETSIZE 1024
#endif

Исправление firkax, :

С long-ом - переносима везде кроме винды (там не битовые массивы а списки fd). С переопределением FD_SETSIZE - переносима вообще везде (на юниксах оно будет работать как я написал, на винде не влияет т.к. там и без него нет ограничений на номер).

Если у тебя каким-то сраным хером номера fd будут в районе миллиарда, ты будешь сотни метров выделять просто под select()?

Не будут, ядро не позволит. В ядре для списка fd процесса тоже массив и весьма ограниченной длины (и ещё больше ограниченной через sysctl вроде). А если ты даже пересоберёшь ядро чтобы оно разрешало такие fd, то способов сделать такой номер ровно два: либо открыть миллиард дескрипторов одновременно, либо специально сделать dup2() на этот номер. Потому как автоматическое выделение fd (везде, кроме винды, там это вообще не индексы) делается строго по очереди (самый маленький из свободных).

Проблемы у селекта две:

  1. действительно, выделять ради одного дескриптора с номером 10000 (это вполне реально уже в отличие от твоего миллиарда) целый массив в 2250 байт, а затем в ядре в цикле искать в нём этот единственный единичный бит - как-то нехорошо, но эта проблема неактуальна если прога использует всего несколько дескрипторов.

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

Зато у него есть два плюса:

  1. его все знают

  2. это единственный полностью кроссплатформенный способ опроса

А так, если нам заранее известна ОС, то наверно для простых применений удобнее poll (сам его использую для них) а для нагруженных - kqueue или epoll, да.

Так и тянет сунуть в glibc коммит с вот таким:

Да нет, достаточно вырезать ifndef вокруг define который туда вставили специально чтоб можно было переопределять:

#ifndef FD_SETSIZE
#define FD_SETSIZE 1024
#endif

Исправление firkax, :

С long-ом - переносима везде кроме винды (там не битовые массивы а списки fd). С переопределением FD_SETSIZE - переносима вообще везде (на юниксах оно будет работать как я написал, на винде не влияет т.к. там и без него нет ограничений на номер).

Если у тебя каким-то сраным хером номера fd будут в районе миллиарда, ты будешь сотни метров выделять просто под select()?

Не будут, ядро не позволит. В ядре для списка fd процесса тоже массив и весьма ограниченной длины (и ещё больше ограниченной через sysctl вроде). А если ты даже пересоберёшь ядро чтобы оно разрешало такие fd, то способов сделать такой номер ровно два: либо открыть миллиард дескрипторов одновременно, либо специально сделать dup2() на этот номер. Потому как автоматическое выделение fd (везде, кроме винды, там это вообще не индексы) делается строго по очереди (самый маленький из свободных).

Проблемы у селекта две:

  1. действительно, выделять ради одного дескриптора с номером 10000 (это вполне реально уже в отличие от твоего миллиарда) целый массив в 2250 байт, а затем в ядре в цикле искать в нём этот единственный единичный бит - как-то нехорошо, но эта проблема неактуальна если прога использует всего несколько дескрипторов.

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

Зато у него есть два плюса:

  1. его все знают

  2. это единственный полностью кроссплатформенный способ опроса

А так, если нам заранее известна ОС, то наверно для простых применений удобнее poll (сам его использую для них) а для нагруженных - kqueue или epoll, да.

Так и тянет сунуть в glibc коммит с вот таким:

Да нет, достаточно вырезать ifndef вокруг define который туда вставили специально чтоб можно было переопределять:

#ifndef FD_SETSIZE
#define FD_SETSIE 1024
#endif

Исходная версия firkax, :

С long-ом - переносима везде кроме винды (там не битовые массивы а списки fd). С переопределением FD_SETSIZE - переносима вообще везде (на юниксах оно будет работать как я написал, на винде не влияет т.к. там и без него нет ограничений на номер).

Если у тебя каким-то сраным хером номера fd будут в районе миллиарда, ты будешь сотни метров выделять просто под select()?

Не будут, ядро не позволит. В ядре для списка fd процесса тоже массив и весьма ограниченной длины (и ещё больше ограниченной через sysctl вроде). А если ты даже пересоберёшь ядро чтобы оно разрешало такие fd, то способов сделать такой номер ровно два: либо открыть миллиард дескрипторов одновременно, либо специально сделать dup2() на этот номер. Потому как автоматическое выделение fd (везде, кроме винды, там это вообще не индексы) делается строго по очереди (самый маленький из свободных).

Проблемы у селекта две:

  1. действительно, выделять ради одного дескриптора с номером 10000 (это вполне реально уже в отличие от твоего миллиарда) целый массив в 2250 байт, а затем в ядре в цикле искать в нём этот единственный единичный бит - как-то нехорошо, но эта проблема неактуальна если прога использует всего несколько дескрипторов.

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

Зато у него есть два плюса:

  1. его все знают

  2. это единственный полностью кроссплатформенный способ опроса

А так, если нам заранее известна ОС, то наверно для простых применений удобнее poll (сам его использую для них) а для нагруженных - kqueue или epoll, да.