Comments 6
блокирует вызвавшую его рабочую нить
Вечный вопрос, насколько дословно нужно переводить всем известные под оригинальным именем понятия…
+2
> Увеличивается латентность обработки очередного запроса. Так, если в данный момент нет никаких активных запросов и поступает новый входящий HTTP-запрос, то curl-нить получит информацию о нем только после выхода из очередного вызова this_thread::sleep_for().
Если в request_info_queue_t добавить condition variable, то от этой задержки можно избавиться.
Вот например такой псевдокод
Если в request_info_queue_t добавить condition variable, то от этой задержки можно избавиться.
Вот например такой псевдокод
std::condition_variable cond_;
void push(...) {
std::lock_guard<mutex> lock(mut);
// push
cond_.notify_one();
}
void pop(Acceptor && acceptor, function<bool()> func) {
std::unique_lock<mutex> lock(mut);
while (true) {
if (cond.wait_for(lock, milliseconds(50), [](){return !queue_.empty()})) {
break;
} else {
if (func()) { return; }
}
}
// pop elements
}
// Вызов функции
pop(accessor, [](){
int numfds;
curl_multi_wait(..., 0, &numfds);
return numfds != 0;
}
+1
В принципе, да. Но там есть такой фокус, что curl_multi_wait() может возвращать 0 в numfds, даже если сейчас есть выполняющиеся запросы. Поэтому curl_multi_wait() нужно вызывать если still_running != 0, вне зависимости от того, пуста ли очередь или нет. Так что условие для засыпания на condition_variable в pop() будет посложнее.
0
Sign up to leave a comment.
Асинхронные HTTP-запросы на C++: входящие через RESTinio, исходящие через libcurl. Часть 2