Re[7]: Архитектура сетевего приложения.
От: Konstantin  
Дата: 15.11.14 09:50
Оценка:
Здравствуйте, Kernan, Вы писали:

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


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

K>Скедулер решает сколько максимум можно запускать задач на исполнение, остальные задачи просто сидят в очереди и ждут пока освободятся ресурсы. Остальное работает как описал ".".

Вы имеете в в виду вот такую конструкцию:
io_service service_;
ip::tcp::socket sock1(service_);
ip::tcp::socket sock2(service_);
sock1.async_connect( ep, connect_handler);
sock2.async_connect( ep, connect_handler);
deadline_timer t(service_, boost::posix_time::seconds(5));
t.async_wait(timeout_handler);
for ( int i = 0; i < 5; ++i)
    boost::thread( run_service);
void run_service() 
{
    service_.run();
}


То есть у нас один io_service, но несколько тредов на обработку?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.