ситуация весьма странная

процесс даёт открыть только 32768 файловых дескрипторов причём если паралельно октрывать сокеты, то лимит файловых дескрипторов в 32768 будет уменьшаться на число открытых сокетов

главное то, что рабочих сокетов можно открыть больше 32768 (до 200к, как в конфиге), даже если перед этим было открыто файлов под завязку

из sysctl допустим так может быть -

kern.maxfiles: 204800 kern.maxfilesperproc: 200000 kern.openfiles: 43131

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

так в чём может быть дело?

есть идеи, почему pthread_create в какой то момент не возвращает из себя вызов ? тоесть поток уходит на pthread_create и ничего не возвращается - ни ошибок , вообще никакого возврата (смотрел под отладчиком и без него) прога многопоточная, держит очень большие нагрузки до сбоя может от полдня до недели пройти при одинаковых нагрузках

естественно количество созданых-уничтоженных потоков регулируется и вообще статистика системная не показывает ничего необычного, никакого перерасхода ресурсов...

не знаю куда копать

как такое может быть вообще?

код примерно такой -

mov byte [ebx+15],0 ; тут ebx указывает на буффер в памяти

бла бла бла pthread_create

push 300000 call usleep add esp,4

push dword [ebx+10] ; тут всё тот же ebx

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

но вот один раз вывесилось на push dword [ebx+10], причём ebx имел значение указывающее куда то в жопу (0xFF**)

если бы он изначально был неверный, то ошибка был бы на 10 инструкций раньше (см начало)

получается pthread_create или usleep изменили значение ebx - такое разве допускается?!