Стоит задача написания серьёзного сетевого ПО, где требуется поддержка большого числа одновременных запросов. Есть мысль упростить разработку/отладку/поддержку, заменив использование асинхронного boost::asio API на работу с preemptive-потоками в user-space. Чтобы их можно было плодить миллионами, как в Erlang.
Не подскажете хорошую библиотеку такой многопоточности с поддержкой широкого спектра системных вызовов (linux)? Erlang не предлагать.
Вообще, вы правы, в данном случае вполне можно обойтись кооперативной. На удобство отладки это почти не повлияет. Просто не хотелось бы думать о педаче управления, да и встраивать сторонний ресурсоемкий код проще.
Вижу, что хорошей вытесняющей библиотеки нету (непонятно, почему). А из корпоративной что есть?
Да, похоже что никак. Мне казалось что поскольку в стандарте С++11 нет указаний как должен выполняться thread, то можно будет выбирать реализацию или у различных компиляторов она разная. Сейчас же я вижу что везде используются обычные kernel-space потоки.
Да, очень медленные, конечно никого не волнует, что на фоне сетевой работы это капля в море, но не важно, давайте экономить на спичках. Использование user-space потоков не даст видимого прироста при работе с сетью производительности в принципе. А если и даст, то изначально что-то было не то и при этом это не связано с потоками.
Почему серьёзные сетевые приложения используют асинхронный API? Ведь можно наплодить тьму потоков, в каждом обрабатываем по запросу - это на порядок проще и в написании и в отладке и в поддержке. Только вот почему-то так не делают. А не делают потому, что поток съедает много ресурсов ядра (память), а ещё потоки очень медленно управляются (создаются/уничтожаются/подключаются), кроме того есть серьёзные ограничения на количество потоков, примитивов синхронизации и так далее.
Не думаю, что вытесняющая многозадачность в userspace на нативном коде возможна. Если вы запустили какой-то код на исполнение, то вы уже его из userspace не сможете проконтролировать.
В том же erlang есть виртуальная машина, которая управляет исполнением.
Можете еще попробовать golang, если не нравится erlang. Хотя там вроде тоже легкие потоки построены на основе сопрограмм
