А давно дескрипторы сокетов стали рандомно выделяться?

Выдали свободный — пользуйся. А суть вопроса. Это всеравно что: google -> как сделать айди по порядку

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

Покажи код.

Схренали? Не по порядку потому что выдали кому-то другому.

Кому-то другому не могли, я один. Внутри процесса пространство значений дескрипторов виртуальное и изолированное от других процессов и растёт от нуля.

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

Системный вызов select() имеет неудобное API, которое лучше работает с маленькими номерами дескрипторов. Так что обычно они с 0 вяло растут.

в glibс - посрать. да и вообще, даже в кернеле там если и может быть «оптимизация», то слишком незаметная на фоне скорости сетевого обмена.

Нет, не посрать. Во-первых надо извращаться, чтобы передать fd_set больше стандартных 8192. Во-вторых, если дескриптор и в самом деле 100-миллионный, то select() должен копировать в ядро 12 мегабайт битовых полей на каждый fd_set. А эти битовые поля еще все прочитать надо. Многие приложения даже размер буфера в read() не задают такой большой.

Какой glibc? какое ядро? Вообще похоже на какой-то неинициализированный мусор.

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

такой. обработка дескрипторов select'ом может быть разной только в ядре, там теоретически можно указывать их длину. но на уровне glibc эта возможность зарезана и длина дескриптора фиксирована. так что никакой разницы между «маленькими» и «большими» идентификаторами в юзерспейсе просто нет.

man 2 select

Я серьёзно. Открой man и почитай.

Там проблема с размером fd_set, который, как правило, лежит в стеке. Если дескриптор слишком большой (на линуксе обычно > 1024, на солярисе > 65000 с чем-то), то ты просто попортишь стек, да так, что valgrind не сразу укажет место. Особенно феерично, когда программа, которая до этого годами прекрасно работала на солярисе, начинает вдруг чудить страшным образом на линуксе

А ты не проверял на предмет того, не остаются ли висеть у тебя в системе CLOSE_WAIT? Может быть, у тебя утечка?

там именно это и написано. и в сети иногда даже ссылочка прилеплена на баг (ну или фичу, это как посмотреть) в glibc. но в любом случае эта разница несущественна, потому что такие операции сами по себе медленные и экономия на спичках не сделает погоды.

эмм... а почему в стеке, собственно? это уж как программист решит. идиотов, которые пихают в стек массивы в 1024 элемента, я пока не видела.

Мда... Суть от тебя явно ускользнула.

Множества дескрипторов в select начинаются с нуля. И они не разреженные. Поэтому если дескрипторы будут случайно выдаваться в рамках 32-битных чисел, иногда придётся для этих множеств пятисотмегабайтные битовые поля выделять. И на каждый вызов такие массивы в ядро передавать, которое будет их сканить.

Ну и какой вообще смысл в регулируемом размере тогда?

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

идиотов, которые пихают в стек массивы в 1024 элемента

Glibc выделяет на стеке как минимум 1024 байта в некоторых функциях. Я не проверял, но это число может быть и больше.

неудобное API, которое лучше работает с маленькими номерами дескрипторов

ого, прикольно. мимо проходил, не сишник, но интересно. как это?

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

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

Хм... Видимо, я тогда смотрел в какую-то старую версию glibc. Сейчас гляжу в код, а getpwnam выделяет буфер в куче.

select() принимает битовые массивы, где каждый дескриптор - бит.

Если дескрипторы большие (например, 10 миллионов), то копирование в ядро начинает занимать заметное время.

select(): http://lxr.free-electrons.com/source/fs/select.c#L551

get_fd_set() / set_fd_set(): http://lxr.free-electrons.com/source/include/linux/poll.h#L130

линейный перебор в do_select(): http://lxr.free-electrons.com/source/fs/select.c#L432

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

вопрос ведь в том, насколько оно «заметное» со стороны юзерспейсной софтины. думаю, для 99.99% софта это вообще до фени и никто не заметит разницы.

У юзерспейса 2 проблемы: 1. Нужно извращаться, чтобы передать дескрипторы размером больше FD_SETSIZE: завершать программу или увеличивать FD_SETSIZE. Обычно этого не делают и получают некорректные программы, которые в лучшем случае падают. В худшем порят данные.

В примере ниже я это сделал переопределив __FD_SETSIZE (жутко непортабельно).

2. Падение производительности. Это лучше замерять на конкретном примере. Допустим, мы хотим иметь один(!) 200 миллионный дескриптор (в предположении, что select() работает примерно одинаково быстро на маленьких и больших дескрипторах). dup2() легко нам позволит такой создать.

#define _BITS_TYPES_H
#include <bits/typesizes.h>
#undef _BITS_TYPES_H

#define BIG_FD       200000000
#define __FD_SETSIZE 400000000

#include <sys/select.h> /* select() */
#include <errno.h>      /* errno */
#include <stdio.h>      /* printf() */
#include <string.h>     /* strerror() */
#include <unistd.h>     /* dup2() */
#include <stdlib.h>     /* exit() */
#include <sys/resource.h> /* getrlimit() */

fd_set wr; /* larger than stack */

int main() {
    int r;
    int i;
    struct rlimit fd_limits;

    printf ("INFO: sizeof(fd_set)=%zu\n", sizeof(fd_set));

    r = getrlimit (RLIMIT_NOFILE, &fd_limits);
    if (r == -1) {
        printf ("ERROR: getrlimit failed: %i/%s\n", r, strerror(errno));
        exit (1);
    }
    printf ("initial limits: cur=%zu/max=%zu\n", (size_t)fd_limits.rlim_cur, (size_t)fd_limits.rlim_max);

    if (fd_limits.rlim_max < BIG_FD) {
        printf ("HINT: allow more open files:\n");
        printf ("      # sysctl -w sysctl -w fs.nr_open=3000000\n");
        printf ("      $ ulimit -n 2000000\n");
    }

    fd_limits.rlim_cur = fd_limits.rlim_max = BIG_FD + 64;

    r = setrlimit (RLIMIT_NOFILE, &fd_limits);
    if (r == -1) {
        printf ("ERROR: setrlimit failed: %i/%s\n", r, strerror(errno));
        exit (2);
    }

    r = dup2(STDOUT_FILENO, BIG_FD);
    if (r == -1) {
        printf ("ERROR: dup2 failed: %i/%s\n", r, strerror(errno));
        exit (4);
    }

    for (i = 0; i < 3; ++i) {
        printf ("%u: zero out\n", i);
        FD_ZERO(&wr);
        printf ("%u: set bit\n", i);
        FD_SET(BIG_FD, &wr);

        r = select (BIG_FD + 1, NULL, &wr, NULL, NULL);
        if (r == -1) {
            printf ("ERROR: select() failed: %i/%s\n", r, strerror(errno));
            exit (5);
        }
        if (FD_ISSET(BIG_FD, &wr))
            printf ("%u: yay!\n", i);
    }
    return 0;
}

Замеряем задержки:

$ gcc -O2 a.c -o a && sudo strace -r ./a
...
     0.000028 write(1, "INFO: sizeof(fd_set)=50000000\n", 30INFO: sizeof(fd_set)=50000000
) = 30
     0.000027 getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
     0.000024 write(1, "initial limits: cur=1024/max=409"..., 34initial limits: cur=1024/max=4096
) = 34
     0.000027 write(1, "HINT: allow more open files:\n", 29HINT: allow more open files:
) = 29
     0.000024 write(1, "      # sysctl -w sysctl -w fs.n"..., 47      # sysctl -w sysctl -w fs.nr_open=3000000
) = 47
     0.000026 write(1, "      $ ulimit -n 2000000\n", 26      $ ulimit -n 2000000
) = 26
     0.000026 setrlimit(RLIMIT_NOFILE, {rlim_cur=200000064, rlim_max=200000064}) = 0
     0.000024 dup2(1, 200000000)        = 200000000
     0.209725 write(1, "0: zero out\n", 120: zero out
) = 12
     0.019051 write(1, "0: set bit\n", 110: set bit
) = 11
     0.000070 select(200000001, NULL, [], NULL, NULL) = 1 ()
     0.042828 write(1, "0: yay!\n", 80: yay!
)  = 8
     0.000112 write(1, "1: zero out\n", 121: zero out
) = 12
     0.003194 write(1, "1: set bit\n", 111: set bit
) = 11
     0.000201 select(200000001, NULL, [], NULL, NULL) = 1 ()
     0.053294 write(1, "1: yay!\n", 81: yay!
)  = 8
     0.000119 write(1, "2: zero out\n", 122: zero out
) = 12
     0.003957 write(1, "2: set bit\n", 112: set bit
) = 11
     0.000058 select(200000001, NULL, [], NULL, NULL) = 1 ()
     0.044225 write(1, "2: yay!\n", 82: yay!
)  = 8
     0.000059 exit_group(0)             = ?
     0.066349 +++ exited with 0 +++

Что видим: задержка вызова select() минимум 42 (42, 53, 44) миллисекунды. Время выводится перед каждым write() сразу после select() (strace замеряет время между системными вызовами):

     0.000070 select(200000001, NULL, [], NULL, NULL) = 1 ()
     0.042828 write(1, "0: yay!\n", 80: yay!

     0.000201 select(200000001, NULL, [], NULL, NULL) = 1 ()
     0.053294 write(1, "1: yay!\n", 81: yay!

     0.000058 select(200000001, NULL, [], NULL, NULL) = 1 ()
     0.044225 write(1, "2: yay!\n", 82: yay!

Это значит, что больше, чем 24 (1/0.042) раза в секунду на одном ядре select() вызвать не получится.

Не очень-то много :)

Читателю предлагается поиграться с числом циклов и числом в BIG_FD :)

селект уже давно легаси. epoll и poll как бы есть.

это не считая что афтар ошибся.

IMHO, полагаться в программе на какие-то предположения о порядке выделения дескрипторов, значит быть ССЗБ и обрекать программу на UB.

Если только из любознательности... но и любознательность можно направить на что-то заведомо более полезное.