Количество открытых дескрипторов

все-таки проще будет так:

unsigned int count = 0;
DIR* d = opendir ("/proc/self/fd");
while (readdir (d))
count++;
printf ("fd: %u\n", count - 2); // исключаем "." и ".."
closedir (d);

ps если в glibc есть уже готовая функция - мне будет интересно узнать

libc наботает на уровне FILE*, а не int fd.

>libc наботает на уровне FILE*, а не int fd.

Ого...интере-е-есно.... то есть когда я делаю int fd=socket(...), и мне возвращается дескриптор, то внутри libc файловый поток заводится???

Извинитттте.... что-то не верится.... даже, если так, где функа, возвращающая количество потоков?

PS Вообще-то, с точностью до наоборот! Это FILE* является обёрткой для int fd.

Другие мнения? Я вот, судя по всему, ковыряниями в манах и сорцах прихожу к печальному выводу об __отсутствии__ такого вызова в libc.

Как уже упомянули сам libc мало что знает про файловые дескрипторы

int i, coun;

for (i = OPEN_MAX, coun = 0; i--; )
{
  coun += (fcntl(i, F_GETFD) >= 0);
}

Под libc он имел в виду Сишное libc, а не системные вызовы и их обертки.

>Как уже упомянули сам libc мало что знает про файловые дескрипторы

Я и не говорю, что libc должна всё это знать. А вот getrusage берёт данные откуда? Из libc? Ниразу! Из ядра(см. linux/resource.h)! А уж кернелу-то хорошо известно сколько fd сожрал процесс... он и следит за этим и в /proc выводит.

Вопрос, на самом деле, можно переформулировать так: "Есть ли системный вызов, возвращающий тем или иным образом кол-во окрытых процессом дескрипторов?"

PS Приведённый код с последовательным F_GETFD нерационален в случаях расширенного OPEN_MAX и частых запросов. Печально, если это единственный из __системных__ вариантов решения.

>Под libc он имел в виду Сишное libc, а не системные вызовы и их обертки.

Похвально! Но мне ответ на вопрос нужен, а не исследования принципов и алгоритмов libc... за что отдельное спасибо!

> Вопрос, на самом деле, можно переформулировать так: "Есть ли системный вызов, возвращающий тем или иным образом кол-во окрытых процессом дескрипторов?"

AFAIK нет. да и зачем?

// wbr

>AFAIK нет. да и зачем?

Бля! А зачем есть вызов, возвращающий `long int ru_msgsnd' - Number of IPC messages sent?????

Кто-нибудь из вас хоть раз пользовал??? Да никто! Или `long int ru_inblock' - The number of times the file system had to read from the disk on behalf of PROCESSES? Или число контекст-свичей?? А?!

Мне вот число дескрипторов понадобилось! И не сколько раз процесс выпадал в своп или много ли rss сожрал!....ЗНАЧИТ НАДО!

....фуууххх....

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

Спасибо за помощь!..Нет, значит нет...

> Бля! А зачем есть вызов, возвращающий `long int ru_msgsnd' - Number of IPC messages sent????? Кто-нибудь из вас хоть раз пользовал??? Да никто! Или `long int ru_inblock' - The number of times the file system had to read from the disk on behalf of PROCESSES? Или число контекст-свичей?? А?!

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

> Мне вот число дескрипторов понадобилось! И не сколько раз процесс выпадал в своп или много ли rss сожрал!....ЗНАЧИТ НАДО!

значит облом. можно читать конечно же /proc/self/fd, но тут могут быть рейсы.

> Спасибо за помощь!..Нет, значит нет...

да не за что :)

// wbr

> /proc/self/fd

А в не-linux?

> А в не-linux?

$ ls -ln /proc/self/fd
total 0
crw--w----  1 1000  4    5, 0 Feb  5 18:13 0
crw--w----  1 1000  4    5, 0 Feb  5 18:13 1
crw--w----  1 1000  4    5, 0 Feb  5 18:13 2
lr-xr-xr-x  1 1000  100     0 Feb  5 18:13 3 -> /proc/23218

ls: /proc/self/fd/4: No such file or directory
lr-xr-xr-x  1 1000  100     0 Feb  5 18:13 4

$ uname -a
NetBSD NBSD1 4.99.4 NetBSD 4.99.4 (GENERIC) #0: Wed Nov 22 21:25:30 NOVT 2006  toor@NBSD1:/usr/build/obj/sys/arch/i386/compile/GENERIC i386

// wbr

А если убрать procfs из fstab?:)

> А если убрать procfs из fstab?:)

значит не будет. впрочем, на FreeBSD 5.4 fd/ я вообще не вижу so сам по себе метод явно слабо переносим.

// wbr