[Development] About "finish" signal in QHttpNetworkConnectionChannel

song.7.liu at nokia.com song.7.liu at nokia.com
Fri Jul 20 04:47:57 CEST 2012


It seem I know that it is avoiding "wake up" again if it's already alive.
And the wakeUps._q_value is 1 in my case,  but this main thread actually is pending at doSelect, so I don't know why wakeUps is not zero !

From: development-bounces+song.7.liu=nokia.com at qt-project.org [mailto:development-bounces+song.7.liu=nokia.com at qt-project.org] On Behalf Of Liu Song.7 (Nokia-MP/Beijing)
Sent: Friday, July 20, 2012 10:27 AM
To: markus at woboq.com; development at qt-project.org
Subject: Re: [Development] About "finish" signal in QHttpNetworkConnectionChannel

Hi,

Thanks, and now the "root cause" is found, that the "finished" signal is posted to the main thread, and also it will try to wake up the main thread:

void QEventDispatcherUNIX::wakeUp()
{
    Q_D(QEventDispatcherUNIX);
    if (d->wakeUps.testAndSetAcquire(0, 1)) {
        char c = 0;
        qt_safe_write( d->thread_pipe[1], &c, 1 );
    }
}

But "d->wakeUps.testAndSetAcquire(0, 1)" returns zero, so eventually the main thread's event loop is not triggered.

Can someone share what's the purpose of using testAndSetAcquire here ?

Thanks,
Song

From: development-bounces+song.7.liu=nokia.com at qt-project.org<mailto:development-bounces+song.7.liu=nokia.com at qt-project.org> [mailto:development-bounces+song.7.liu=nokia.com at qt-project.org]<mailto:[mailto:development-bounces+song.7.liu=nokia.com at qt-project.org]> On Behalf Of ext Markus Goetz
Sent: Friday, July 20, 2012 3:32 AM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] About "finish" signal in QHttpNetworkConnectionChannel

On 19.07.12 17:55, song.7.liu at nokia.com<mailto:song.7.liu at nokia.com> wrote:
Hi,
I am using the QNetworkAccessManager::get to request content from http://www.google.com.
Then the QHttpNetworkConnectionChannel will be created and worked on another thread, when all the data is received, the QHttpNetworkConnectionChannel::allDone will be invoked, where:

    // queue the finished signal, this is required since we might send new requests from
    // slot connected to it. The socket will not fire readyRead signal, if we are already
    // in the slot connected to readyRead
    if (reply && emitFinished)
        QMetaObject::invokeMethod(reply, "finished", Qt::QueuedConnection);

So this "finished" signal will be queued in the thread of QNetworkReplyHttpImpl until a new event will be handled.

Finally, my application also won't receive any finished signal until for example: touch the screen to trigger the queued signal be handled.

So why using the type Qt::QueuedConnection for this "finished" signal ? is there something wrong in my side ?

The finished() communicated will be "queued" anyway nowadays since the inter-thread communication (from HTTP thread to your user thread) is happening via the event loop. Also it is not queued until a new event will be handled, it should flow to your user thread without further delay.

I have no idea right now why your issue could happen => https://bugreports.qt-project.org

bye,
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120720/d5eb0765/attachment.html>


More information about the Development mailing list