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

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

K>>У нас есть главный поток приложения, в котором мы создаем класс, который отвечает за очередь команд. Предположим что-то типа FIFO стека.
K>>Когда юзер нажимает на кнопу старт (к примеру) мы в эту очередь добавляем задание с параметрами. Предположим, что очередь сделана на основе io_service + thread pool. Тогда мы создаем число тредов, равное числу ядер процессора для оптимума. Обработчик очереди извлекает задания из очереди... И... ? Например, если это задание "записать в файл" или в БД, то понятно что можно его там и выполнить. А если это задание "скачать файл" ? То гда ведь надо еще какую-то очередь на скачивание иметь с тредами и потом оттуда по завершении сообщать результат... Или как быть? Вот тут не совсем понятен вопрос.
.>Число тредов по числу ядер это если все треды будут занимать процессор, т.е. вычисления, а не ввод-вывод (запись в файл, бд, скачка).
.>Поэтому можно в простом случае и одну очередь иметь c бОльшим числов тредов-обработчиков. Но таки да, для приоритетов, управлением параллелизации можно завести несколько очередей.
.>Сообщать результат никуда не надо, просто в ту же очередь (или очередь команд UI) класть задание "нарисовать диалог с ответом".

Приоритеты не важны. Пускай все выполняется по очереди. Но предположим, если у нас будет один io_service, то может возникнуть такая ситуация: (если взять за основу пример гуглбота) Скачали страницу, а на ней 10000 ссылок. То есть одно задание на скачку породило 10000 заданий на скачивание. Для одного io_service я бы сказал, что это не хорошо, потому что во-первых цикл select/epoll будет тормозить, да и хотелось бы ограничить число одновременных коннектов.