Boost thread - ограниченное количество потоков?, непонятное ограничение, не связанное с ресурсами системы Опции

[Iron Bug]

добрый день всем.
вот, может, кто сталкивался с подобной проблемой:
использую библиотеку thread boost'а для кроссплатформенного программирования. до недавего времени всё было замечательно, но тут возникло одно неприятное открытие:
оказалось, что буст почему-то ограничивает возможное количество потоков. а именно: после создания какого-то числа работающих потоков создание очередного потока проваливается с исключением boost::thread_resource_error и до уменьшения количества работающих потоков создание нового потока невозможно (каждый раз выпадает это исключение). причём это максимальное число потоков не зависит от реальных ресурсов системы, либо зависимость мне непонятна.
для проверки была написана маленькая программа - генератор потоков. потоки просто создаются, спят какое-то время, потом завершаются. потоки пустые, мелкие - то есть, памяти теоретически должно хватать. при этом задавалось разное время жизни потоков и разное количество потоков. результаты по подсчёту количества потоков всегда одинаковы, независимо от времени жизни каждого потока. это число каким-то загадочным образом зависит от машины, но, по видимому, не зависит от количества свободной памяти процесса и системы.
из опытов получилась такая странная картина: дома стоит машина под линюксом, 4 гектара памяти, своп вообще не используется - опытным путём получен предел в 382 потока, на работе машина под вендой, 1 гектар памяти, предел - 2024 потока. увеличение-уменьшение количества других процессов в системе никак не влияет.
откуда берутся такие странные цифры? может, есть возможность определить каким-то образом, как распределять ресурсы, чтобы потоков было больше? по работе необходима возможность одновоеменного выполнения очень большого и заранее неопределённого количества потоков в риал-тайме (пул потоков как бы не подходит по замыслу задачи). непонятно, откуда исходит это ограничение и как с ним бороться (если это вообще возможно).

[Iron Bug]

ну, тут много деталей... если даже виртуальная машина и быстрая (что, мягко говоря, сомнительно) - то как её связать с реальным железом, у которого может не быть стандартных драйверов и стандартных интерфейсов? боюсь, что тут гемора будет выше крыши. хотя вычислений у меня не так много и они простые, зато надо постоянно и шустро парсить поток байтов с драйвера и вылавливать из него нужные данные. так что тут задача довольно специфическая. вообще, к телекому это отношения не имеет: это обработка данных от специально разработанного железа и управление точной механикой на очень большой скорости. то есть, автоматизация промышленных процессов. сетевого взаимодействия на уровне тестирования просто нет. все данные льются по спецшинам и ДМА в корзину, где и обрабатываются. довольно специфическая задача, со своими требованиями.
что касается Эрланга... я бегло просмотрела в сети отзывы народа про него... судя по отзывам, Эрланг вроде как не используется для таких задач, как у нас. что он быстрее С# - ну дык... гы! меня шарп вообще не интересует ни с какой стороны, ибо дикие тормоза и чисто прикладная реализация, в принципе не рассчитанная на низкоуровневую работу с железом. для стандартных интерфейсов это может быть и проканает, но очень маловероятно, что в него можно внедрить работу с межпроцессным адресным пространством, различными системными объектами и фреймами ДМА в памяти. отзывы в плюс Эрлангу - в основном по объёму кода. но мне совершенно фиолетово на объём - мне не лень писать код, лишь бы он работал быстро и надёжно. конечно, оптимизация может быть во всём, но объём кода тут на самом последнем месте. к тому же всякие автоматические сборки мусора напрягают сразу: это означает фактическую непредсказуемость работы системы. я думаю, если в промышленной автоматизации и системном программировании никто за столько лет не написал ничего на таких языках - то это неспроста. так что я всё же придерживаюсь программирования на Си: простой и надёжный язык, на нём можно написать всё, что только захочется. а про Эрланг - ну, если появится время, можно будет глянуть спецификацию более детально. однако пока что мне кажется, что он не подходит для моих задач.