Сообщение Re[6]: Архитектура сетевего приложения. от 14.11.2014 10:18
Изменено 14.11.2014 10:19 Kernan
Здравствуйте, Konstantin, Вы писали:
K>Приоритеты не важны. Пускай все выполняется по очереди. Но предположим, если у нас будет один io_service, то может возникнуть такая ситуация: (если взять за основу пример гуглбота) Скачали страницу, а на ней 10000 ссылок. То есть одно задание на скачку породило 10000 заданий на скачивание. Для одного io_service я бы сказал, что это не хорошо, потому что во-первых цикл select/epoll будет тормозить, да и хотелось бы ограничить число одновременных коннектов.
Скедулер решает сколько максимум можно запускать потоков на исполнение, остальные задачи просто сидят в очереди и ждут пока освободятся ресурсы. Остальное работает как описал ".".
K>Приоритеты не важны. Пускай все выполняется по очереди. Но предположим, если у нас будет один io_service, то может возникнуть такая ситуация: (если взять за основу пример гуглбота) Скачали страницу, а на ней 10000 ссылок. То есть одно задание на скачку породило 10000 заданий на скачивание. Для одного io_service я бы сказал, что это не хорошо, потому что во-первых цикл select/epoll будет тормозить, да и хотелось бы ограничить число одновременных коннектов.
Скедулер решает сколько максимум можно запускать потоков на исполнение, остальные задачи просто сидят в очереди и ждут пока освободятся ресурсы. Остальное работает как описал ".".
Re[6]: Архитектура сетевего приложения.
Здравствуйте, Konstantin, Вы писали:
K>Приоритеты не важны. Пускай все выполняется по очереди. Но предположим, если у нас будет один io_service, то может возникнуть такая ситуация: (если взять за основу пример гуглбота) Скачали страницу, а на ней 10000 ссылок. То есть одно задание на скачку породило 10000 заданий на скачивание. Для одного io_service я бы сказал, что это не хорошо, потому что во-первых цикл select/epoll будет тормозить, да и хотелось бы ограничить число одновременных коннектов.
Скедулер решает сколько максимум можно запускать задач на исполнение, остальные задачи просто сидят в очереди и ждут пока освободятся ресурсы. Остальное работает как описал ".".
K>Приоритеты не важны. Пускай все выполняется по очереди. Но предположим, если у нас будет один io_service, то может возникнуть такая ситуация: (если взять за основу пример гуглбота) Скачали страницу, а на ней 10000 ссылок. То есть одно задание на скачку породило 10000 заданий на скачивание. Для одного io_service я бы сказал, что это не хорошо, потому что во-первых цикл select/epoll будет тормозить, да и хотелось бы ограничить число одновременных коннектов.
Скедулер решает сколько максимум можно запускать задач на исполнение, остальные задачи просто сидят в очереди и ждут пока освободятся ресурсы. Остальное работает как описал ".".