Как QtConcurrent::run оказывается в основном потоке?

Я построил в своем приложении фасад асинхронной сети на основе QFuture. Примерно это работает так:

namespace NetworkFacade {
    QByteArray syncGet(const QUrl& url) {
        QEventLoop l;
        QByteArray rc;

        get(url, [&](const QByteArray& ba) {
            rc = ba;
            l.quit();
        });

        l.exec();
        return rc;
    }

    void get(const QUrl& url, const std::function<void (const QByteArray&)>& handler) {
        QPointer<QNetworkAccessManager> m = new QNetworkAccessManager;

        QObject::connect(m, &QNetworkAccessManager::finished, [=, &m](QNetworkReply *r) {
            QByteArray ba;

            if (r && r -> error() == QNetworkReply::NoError)
                ba = r -> readAll();

            m.clear();

            if (handler)
                handler(ba);
        });
        m -> get(QNetworkRequest(url));
    }
}

У меня есть QTimer, который запускает вызов в основном потоке, который делает следующее (очевидно, упрощенно):

foreach(Request r, requests) {
    futures.push_back(get(r));
}

foreach(QFuture<SomeType> f, futures) {
    f.waitForFinished();
    [do stuff with f.result()]
}

Я предполагал, что waitForFinished() заблокирует основной поток, в то время как фоновые потоки будут выполнять мои сетевые запросы. Вместо этого я получаю ошибку qFatal:

ASSERT: "m_blockedRunLoopTimer == m_runLoopTimer" in file eventdispatchers/qeventdispatcher_cf.mm, line 237

В трассировке стека я вижу свой waitForFinished() в основном потоке, но вместо того, чтобы быть заблокированным, я вижу (читать снизу вверх):

com.myapp   0x0008b669 QEventDispatcherCoreFoundation::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 1753
com.myapp   0x000643d7 QIOSEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 823
com.myapp   0x0130e3c7 QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 119
com.myapp   0x0130e5fb QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 539
com.myapp   0x0003a550 NetworkFacade::syncGet(QUrl const&) + 208
com.myapp   0x00037ed1 QtConcurrent::StoredFunctorCall0<std::__1::shared_ptr<QuoteFacade::Quote>, QuoteFacade::closingQuote(QString const&, QDate const&)::$_0>::runFunctor() + 49
com.myapp   0x00038967 QtConcurrent::RunFunctionTask<std::__1::shared_ptr<QuoteFacade::Quote> >::run() + 87
com.myapp   0x00038abc non-virtual thunk to QtConcurrent::RunFunctionTask<std::__1::shared_ptr<QuoteFacade::Quote> >::run() + 28
com.myapp   0x010dc40f QThreadPoolPrivate::stealRunnable(QRunnable*) + 431
com.myapp   0x010d0c35 QFutureInterfaceBase::waitForFinished() + 165

Таким образом, вместо того, чтобы ждать, пока QFuture получит значение, моя предположительно параллельная задача выполняется в основном потоке. Это приводит к вызову описанной выше функции get(), которая отслеживает события в QEventLoop. Тем временем QTimer снова срабатывает, и я получаю утверждение сверху.

Я делаю что-то не так, или вполне допустимо, что QtConcurrent::run может привести к тому, что управление вернется к основному потоку?

=== Обновление 1

@peppe: выполняемая лямбда просто выполняет HTTP GET и генерирует анализирует ответ JSON в объект SomeType. Доступ к результату осуществляется через функцию QFuture.

=== Обновление 2

Видимо это по замыслу. Из qfutureinterface.cpp из Qt 5.4.0 строки 293-295:

// To avoid deadlocks and reduce the number of threads used, try to
// run the runnable in the current thread.
d->pool()->d_func()->stealRunnable(d->runnable);