Ограничение доступа к файлу-обработчику 256

Question

В моем коде открывается более 256 файловых дескрипторов, поэтому, когда я запускаю его на компьютерах Solaris, я заканчиваю ошибку «Превышение ограничителей файлов».

У меня есть два вопроса относительно этого

1) Является ли это ограничение только для 32-битного программного обеспечения или 64 бит программного обеспечения, также страдает от него. Я разобрался в этом и узнал, что у 64-битных программ нет этого ограничения. (http://developers.sun.com/solaris/articles/stdio_256.html) Но я построил статический 64-битный объект, и когда я его использую, он дает ошибку. Что означает 64-битное программное обеспечение?

2) Как указано в приведенной выше ссылке, я использовал ulimit для увеличения ограничения файловых обработчиков (во время выполнения, я имею в виду, прежде чем запускать команду), экспортировал библиотеку расширенных файлов, и у меня нет никакой ошибки. Что нам нужно сделать Linux?

Благодаря Д. Л. Кумар

Answer 1

Чтобы проверить, если объектный файл (исполняемый файл) является 64-бит, используйте командный файл (по крайней мере на Linux).

Например:

$ file `which ls` 
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped 

$ file my-32bit-exe 
my-32bit-exe: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), corrupted section header size 

(Не возражает «поврежденного размер заголовка раздела» - ехе был вручную подогнан, чтобы уменьшить размер файла).

ulimit можно использовать в Linux (см. ulimit(1) и ulimit(3)).

Answer 2

Я столкнулся с этим раньше. Насколько я могу судить, на самом деле это ошибка в libc Solaris, где они используют 8-разрядный целочисленный тип без знака для хранения fd в структуре FILE. По-видимому, они не изменили его очень быстро во имя обратной совместимости (в случае, если программа по какой-то причине зависела от деталей реализации структуры FILE). Это должно быть NOT быть проблемой для Linux или любого другого non-solaris * nix. В статье, которую вы цитировали, были предложены разумные способы обхода, поэтому вы должны использовать их.

Что касается «что такое 64-разрядный исполняемый файл», то это всего лишь двоичный файл, который был скомпилирован для 64-битного набора команд. Некоторые архитектуры поддерживают, а некоторые нет. (Например, ОС x86-64 обычно позволяют 32-битные процессы для обратной совместимости).

Answer 3

В Solaris, вы строите 64-битные программы с использованием:

cc -xarch=v9 ... 

Или:

gcc -m64 ... 

Как сказал Эван, основная проблема для 32-разрядной ОС Solaris имеет обратный бинарную совместимость и 8-битное целое, используемое для хранения fd.

Я просто попробовал этот код на Solaris 10 для SPARC:

#include <stdio.h> 

int main(void) 
{ 
    size_t i; 
    for (i = 0; i < 300; i++) 
    { 
     FILE *fp = fopen("/dev/null", "a"); 
     if (fp == 0) 
     { 
      printf("Failed on %zu\n", i); 
      return(1); 
     } 
    } 
    printf("Succeeded to %zu\n", i); 
    return(0); 
} 

Составитель как:

cc -xarch=v9 -o xxx xxx.c 

И он дал мне 'не удалось на 253'. (Это тестовый код: я знаю, что он выбрасывает 252 указателя.) Это подтверждает ваше утверждение о том, что простая 64-битная сборка. Тем не менее, есть еще один фактор игры - ограничения ресурсов.

$ ulimit -n 
256 
$ 

Таким образом, увеличение лимита по умолчанию с:

$ ulimit -n 400 
$ ulimit -n 
400 
$ ./xxx 
Succeeded to 300 
$ 

Попробуйте это ...

Answer 4

Как Эван Теран упоминалось, Солярис Libc имеет это «странное» ограничение на файл, который может только обрабатывать дескрипторы файлов под 256.

Это независимо от того ограничения, который вы можете установить с помощью ulimit. Вы можете установить этот предел от жгутов вашей программы:

#include <sys/resource.h> 

struct rlimit rl; 
getrlimit(RLIMIT_NOFILE,&rl); 
rl.rlim_cur = 1024; /* change it to 1024 - note has to be < than rl.rlim_max */ 
setrlimit(RLIMIT_NOFILE,&rl); 

Теперь я хотел бы также прекратить использование FILE * и использовать открытый вместо FOPEN, и т.д. и т.п. Для случаев вы действительно, действительно необходимы использовать FILE *, по нескольким проектам, с которыми я работал, в начале программы несколько дескрипторов файлов были «зарезервированы», выполнив вызов сокета, и у нас была небольшая библиотека, чтобы получить FILE *, используя их, закрыв один из сокетов и сразу после что делает fopen, который будет использовать только что закрытый fd. Конечно, нужно было бы также закрыть FILE * специальной функцией, которая будет закрываться, а затем сразу же получить fd, используя сокет ;-)

Answer 5

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

1), как было предложено выше по njsf

2) Открытие файла с флагом "F", как следует FILE * Fp = FOPEN ("/ DEV/нуль "," wF ");

Большое спасибо. D. L. Kumar