Парсинг ответов QNetworkAccessManager в разных потоках Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Переключить на: Древовидный Стандартный Переключить на: Линейный

[DrWebber]

Всем привет. Возник вопрос как правильно организовать обработку данных в разных потоках?

Есть вот такой класс(схематично):

class Requester : public QObject
{
    Q_OBJECT
    Requester () : QObject(0)
    {
         
         manager = new QNetworkAccessManager;

         QNetworkProxy proxy(QNetworkProxy::DefaultProxy, "127.0.0.1" , 5555);
         manager->setProxy(proxy);

         connect(manager, SIGNAL(finished(QNetworkReply*)), this, SLOT(replyFinished(QNetworkReply*)));
    }

public:
    void sendGET(int id, const QNetworkRequest &req)
    {
      ......
        manager->get(req);
      ......
    }
    void sendPOST(int id, const QNetworkRequest &req, const QByteArray &data)
    {
      ......
        manager->post(req, data);
      ......
    }


private:

    QNetworkAccessManager *manager;

prinvate slots:
    void replyFinished(QNetworkReply* reply);

Экземпляров этого класса может быть....ну допустим 10. Я понимаю, что рекомендуется использовать 1 QNetworkAccessManager в приложении, но мне нужно чтобы запросы отправлялись через разные прокси.
Так же есть класс-генератор запросов, который вызывает функции sendGET и sendPOST, он работает в отдельном потоке QThread. Мне нужно чтобы данные, которые приходят в replyFinished обрабатывались параллельно, т.е. в данном случае в 10 потоков. Я пробовал создавать для каждого Requester свой QThread, но тогда я не мог вызывать из другого потока функции sendGET и sendPOST, вываливалось вот такое сообщение:

QObject: Cannot create children for a parent that is in a different thread.
(Parent is QNetworkAccessManager(0x13963008), parent's thread is QThread(0x13962fe8), current thread is QThread(0x13962fb8)

Создавал вот так:

    Requester *requester = new Requester();

    QThread *thread = new QThread;
    requester->moveToThread(thread);

    QObject::connect(thread, SIGNAL(started()), requester, SLOT(startInThread()));

    QObject::connect(requester, SIGNAL(finished()), thread, SLOT(quit()));
    QObject::connect(requester, SIGNAL(finished()), requester, SLOT(deleteLater()));

    QObject::connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));
    thread->start();

Когда так делал, класс Requester выглядел немного по-другому - вся инициализация была в функции startInThread().

Собственно вопрос: как такое правильно реализовать?

[lanz]

А зачем вообще треды? Создайте 10 экземпляров в одном потоке.
QnetworkAccessManager работает асинхронно, поэтому проблем никаких не будет. В этом же потоке обрабатывайте данные по мере поступления.

[DrWebber]

А зачем вообще треды? Создайте 10 экземпляров в одном потоке.
QnetworkAccessManager работает асинхронно, поэтому проблем никаких не будет. В этом же потоке обрабатывайте данные по мере поступления.

В том-то и дело, что мне нужно чтобы данные обрабатывались в разных потоках, это существенно существенно увеличит производительность. Хоть QnetworkAccessManager и работает асинхронно, ответы все равно будут обрабатываться последовательно, а меня это не устраивает.

[lanz]

В том-то и дело, что мне нужно чтобы данные обрабатывались в разных потоках, это существенно существенно увеличит производительность. Хоть QnetworkAccessManager и работает асинхронно, ответы все равно будут обрабатываться последовательно, а меня это не устраивает.

Вы бенчмарк делали?
А как же переключение потоков? У вас же не 10 процессоров.

Если данные у вас обрабатываются так долго, что один поток не успевает их разобрать между приходами запросов, то 10 потоков вас не спасут, все время будет копится очередь необработанных запросов.

Почитайте например тут
http://programmers.stackexchange.com/quest...e-thread-cannot

[Iron Bug]

Если данные у вас обрабатываются так долго, что один поток не успевает их разобрать между приходами запросов, то 10 потоков вас не спасут, все время будет копится очередь необработанных запросов.

это утверждение неверно. обработка может быть сложной и долгой. а запросы сами по себе могут быть мелкими, но поступать довольно быстро. распараллеливание обработки - совершенно нормальная практика. просто обычно создаются очередь входящих и очередь исходящих сообщений, если это один коннект. и один поток работает с сетью, а остальные заняты обработкой. но про реализацию подобных схем на Qt я ничего сказать не могу.

[lanz]

это утверждение неверно. обработка может быть сложной и долгой. а запросы сами по себе могут быть мелкими, но поступать довольно быстро.

Совершенно согласен, неверно выразился. Под разборкой я имел ввиду парсинг запросов и распределение по потребителям перед их обработкой.

и один поток работает с сетью, а остальные заняты обработкой. но про реализацию подобных схем на Qt я ничего сказать не могу.

На мой взгляд единственно правильная реализация, поскольку работа с сетью как правило IO-bound. В Qt реализуется очень просто через обычный producer-consumer, используя сигналы и слоты например для синхронной доставки.