В настоящее время я работаю над переносом кода в VxWorks. поэтому я использую симулятор для проверки изменений.
Этот код требует открытия многих труб и розеток. У меня проблема с открытием дескрипторов этих файлов. Действительно, я могу открыть 17 файловых дескрипторов (сокеты или каналы вызывают ту же ошибку), но следующее возвращает ошибку «EMFILE: слишком много открытых файлов».
После некоторых исследований в сети я изменил глобальную переменную NUM_FILES, но это изменение не имело никакого эффекта.
Знаете ли вы, если это симулятор, который ограничивает количество файлов дескрипторов, открытых одновременно?
Спасибо за помощь
У меня также были проблемы с недостаточным количеством доступных файловых дескрипторов. настройка NUM_FILES
до 50 или около того решили проблему. Ограничение находится в ядре VxWorks, которое статически размещает таблицу дескрипторов файлов.
Насколько я знаю, меняется NUM_FILES
требует, чтобы ядро было перекомпилировано, так как это значение конфигурации ядра.
Вы можете подсчитать количество свободных файловых дескрипторов, скомпилировав и выполнив следующую функцию в оболочке VxWorks:
int countFreeFds(void)
{
int count = 0;
int i;
FILE *fd[100];
for (count = 0; count < 100; count++)
{
fd[count] = fopen("somefile", "r"); /* some any existing file */
if (fd[count] == NULL)
{
break;
}
}
for (i = (count - 1); i >= 0; i--)
{
fclose(fd[i]);
}
return (count);
}
Если вы сделаете это в только что запущенном VxWorks без дополнительной загрузки двоичного файла или запуска задач, возвращаемое значение countFreeFds
вернет число, близкое к NUM_FILES
,
(также обратите внимание, что я не тестировал вышеописанную функцию, так как сейчас у меня нет доступа к источнику, который я использовал несколько лет назад … вы также можете изменить код для использования сокетов или каналов вместо бесплатные файловые дескрипторы без разницы)
Я нашел проблему
мне пришлось изменить RTP_FD_NUM_MAX
это было конкретное значение RTP