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

[Iron Bug]

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

[Iron Bug]

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

пока что результаты экспериментов в венде:
1. размер стека (параметр линковки) влияет на количество потоков в обратной пропорции. это мне теперь стало понятно: на каждый поток выделяется стек из пула. соответственно, меньше стек - больше потоков. но вот уменьшать размер стека как бы не очень хотелось бы... не то, чтобы дочерние потоки какие-то монстрообразные вглубь и вширь... они, как правило, очень простые и часто даже линейные, но всё же стек есть стек.
2. размер кучи (параметр линковки) не влияет никак
3. размер NonPagedPoolQuota в реестре (вроде как у майкрософта написано, что это есть пул для потока), поставленный в максимум=128 (это число было взято с сайта майкрософта), после перезагрузки машины не дал никакого результата. думаю, общий NonPagedPoolSize (суммарный пул для системы) менять не имеет смысла - ведь остальные приложения жрут и поболе памяти и в сумме при высокой нагрузке на систему венда вполне нормально использует всю память. у меня вообще нет подозрений на нехватку пула. какие-то 60 метров - это вообще пустяки для системы.

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

про линюкс пока туман. буду копать ещё и ставить эксперименты дома.