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

M>Очевидно что 10 пулов с лимитом в 4 потока будут больше простаивать чем 1 пул с лимитом 40.
1. Очевидно, что это утверждение не имеет никакого отношения к решению, делать ли пул синглтоном. Верно?
2. Предыдущее "очевидное" умозаключение оказалось несовместимым с действительностью. Почему ты думаешь, что это утверждение ждет лучшая судьба?
3. В связи с 1 и 2, предлагаю более тщательно подумать над своими заявлениями. Очевидно, что одно осторожное и верное утверждение лучше, чем десять категоричных и неверных, не так ли?

M>Я не утверждаю что такая ситуация присутствует всегда , вы сами привели яркие примеры не вписывающиеся в эту картину.
В какую картину? Синглтон, простите, это как скрижали — высек в камне и живи с ним. Выковырять синглтон из развитого приложения крайне тяжело. Если он подходит лишь для узкого набора частных случаев применения нашей программы/фреймворка/библиотеки, то может быть сразу реализовать общий случай с произвольным количеством пулов? Ибо сузить его на один экземпляр, если это удобно в данном случае, куда как проще, чем провести обратную операцию.
M>Если пул потоков кажется сомнительным кандидатом на сингелтон то могу предложить планировщик задач (алгоритмически вероятно лучше иметь один планировщик).
Слова "вероятно" здесь, наверное, не вполне уместны. Я как бы ожидаю бесспорности от кандидата в синглтоны. Пул потоков, в каком-то смысле, и есть планировщик задач. Тот планировщик, который в операционке, делает, в общем-то, примерно то же, только на другом уровне, и имеет возможность динамически отбирать ресурсы у задачи до ее окончания.
M>З.Ы. Можно в имплементации запланировать различные сценарии и поведение с учетом приоритетов и т.п.
Можно. Но делать такие заявления лучше с осторожностью.