Здравствуйте, minorlogic, Вы писали:

M>Очевидно что 10 пулов с лимитом в 4 потока будут больше простаивать чем 1 пул с лимитом 40.
Очевидно что поток который простаивает не ест ресурсов. Кроме адресного пространства. А если учесть что 64 бита становится обычным делом... Да и 32х бит тоже хватает на очень большое колличество потоков...

M>Я не утверждаю что такая ситуация присутствует всегда , вы сами привели яркие примеры не вписывающиеся в эту картину.
Я тебе могу расказать как можно задедлочится на пуле... но ты почемуто считаешь что это невозможно

M>Если пул потоков кажется сомнительным кандидатом на сингелтон
Он не просто сомнительный.
Это вобще ярчайший пример того что ни в коем случае нельзя делать синглетоном.
Ибо он даст тебе в лоб сразу, а не при поддержке.
Причем не только и не столько тормозами сколько дедлоками.
Хотя производительность тоже важна. Грамотная настройка пулов потоков может поднять производительность системы в десятки, а то и сотни раз плюс обеспечить реактивность (медленные запросы не тормозят быстрые). И все это без переписывания кода. Исключительно правкой конфигов.
А если мы имеем дело с распределенкой то неправильно настроеные пулы могут приводить к распределенным дедлокам (это когда 2 или болие машин лочатся друг на друга). Причем тут даже циклы (машина А спрашивает машину Б, машина Б спрашивает машину А) не нужны.

M>то могу предложить планировщик задач (алгоритмически вероятно лучше иметь один планировщик).
Гм. Вот у меня перед глазами сервачек с сотнями тысяч потоков уровня приложения...
Там есть шедуллер...
Я думаю ты уже догадался что он не синглетон...

M>З.Ы. Можно в имплементации запланировать различные сценарии и поведение с учетом приоритетов и т.п.
Чем слово реализация не устраивает?