Асинхронные HTTP-запросы на C++: входящие через RESTinio, исходящие через libcurl. Часть 2

[alexyr]

блокирует вызвавшую его рабочую нить

Вечный вопрос, насколько дословно нужно переводить всем известные под оригинальным именем понятия…

[eao197]

В русском профессиональном жаргоне для термина thread есть два устоявшихся русскоязычных термина: поток и нить. Оба используются в статье как взаимозаменяемые.

Или вы о чем-то другом?

[alexyr]

я о потоке, нить (кмк) это из серии «дословного перевода»

[eao197]

В контексте C++ слово «поток» оказывается не вполне однозначным, т.к. iostreams — это тоже потоки, но совсем другие, нежели threads. Поэтому в мире C++ термин «нить» вполне себе уместен, как более однозначный.

[svr_91]

> Увеличивается латентность обработки очередного запроса. Так, если в данный момент нет никаких активных запросов и поступает новый входящий HTTP-запрос, то curl-нить получит информацию о нем только после выхода из очередного вызова this_thread::sleep_for().

Если в 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;
}

[eao197]

В принципе, да. Но там есть такой фокус, что curl_multi_wait() может возвращать 0 в numfds, даже если сейчас есть выполняющиеся запросы. Поэтому curl_multi_wait() нужно вызывать если still_running != 0, вне зависимости от того, пуста ли очередь или нет. Так что условие для засыпания на condition_variable в pop() будет посложнее.