Хорошие библиотеки user-space потоков для C++?

Question

[Семён Приходько]

Стоит задача написания серьёзного сетевого ПО, где требуется поддержка большого числа одновременных запросов. Есть мысль упростить разработку/отладку/поддержку, заменив использование асинхронного boost::asio API на работу с preemptive-потоками в user-space. Чтобы их можно было плодить миллионами, как в Erlang.

Не подскажете хорошую библиотеку такой многопоточности с поддержкой широкого спектра системных вызовов (linux)? Erlang не предлагать.

Спасибо.

Comments

[xandox]

А можно пояснить - зачем вам именно вытесняющая многозадачность?

[Семён Приходько]

Вообще, вы правы, в данном случае вполне можно обойтись кооперативной. На удобство отладки это почти не повлияет. Просто не хотелось бы думать о педаче управления, да и встраивать сторонний ресурсоемкий код проще.

Вижу, что хорошей вытесняющей библиотеки нету (непонятно, почему). А из корпоративной что есть?

[Семён Приходько]

*кооперативной

Answer 1

[Павел Сысолятин]

Boost.Coroutine? Вроде бы и asio с ним дружит.

Comments

[Семён Приходько]

Да, на сопрограммах, наверное, можно построить многопоточность, но только кооперативную, я же говорил о вытесняющей.

[Павел Сысолятин]

Есть еще boost.fiber, кажется.

[AxisPod]

Сопрограммы это не потоки, а вот fiber да, что-то типа того, что надо.

[Семён Приходько]

Кирпич - это не дом, но кирпичами дом можно построить.

Answer 2

[synacker]

Если компиляторы поддерживают С++11, то можно и без сторонних библиотек.

Comments

[Семён Приходько]

Позвольте-ка осведомиться, как?

[synacker]

Да, похоже что никак. Мне казалось что поскольку в стандарте С++11 нет указаний как должен выполняться thread, то можно будет выбирать реализацию или у различных компиляторов она разная. Сейчас же я вижу что везде используются обычные kernel-space потоки.

[random-guy]

@ababo а чем плохи обычные kernel-space потоки?

[Семён Приходько]

Тем, что дорогие и медленные.

[AxisPod]

Да, очень медленные, конечно никого не волнует, что на фоне сетевой работы это капля в море, но не важно, давайте экономить на спичках. Использование user-space потоков не даст видимого прироста при работе с сетью производительности в принципе. А если и даст, то изначально что-то было не то и при этом это не связано с потоками.

[Семён Приходько]

Почему серьёзные сетевые приложения используют асинхронный API? Ведь можно наплодить тьму потоков, в каждом обрабатываем по запросу - это на порядок проще и в написании и в отладке и в поддержке. Только вот почему-то так не делают. А не делают потому, что поток съедает много ресурсов ядра (память), а ещё потоки очень медленно управляются (создаются/уничтожаются/подключаются), кроме того есть серьёзные ограничения на количество потоков, примитивов синхронизации и так далее.

[Семён Приходько]

*переключаются

Answer 3

[Лолшто]

Не думаю, что вытесняющая многозадачность в userspace на нативном коде возможна. Если вы запустили какой-то код на исполнение, то вы уже его из userspace не сможете проконтролировать.

В том же erlang есть виртуальная машина, которая управляет исполнением.

Можете еще попробовать golang, если не нравится erlang. Хотя там вроде тоже легкие потоки построены на основе сопрограмм

Comments

[Семён Приходько]

Насколько я понимаю, она реализуется через обработку сигнала таймера и long jump.

[Лолшто]

Вот только сам сигнал таймера пойдет через ядро. Будет ли тогда выгода?

[Семён Приходько]

Да, он довольно редко вызывается — всего несколько раз в секунду.