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....@qt-project.org [mailto:development-bounces+song.7.liu=nokia....@qt-project.org] On Behalf Of Liu Song.7 (Nokia-MP/Beijing) Sent: Friday, July 20, 2012 10:27 AM To: mar...@woboq.com; development@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....@qt-project.org<mailto:development-bounces+song.7.liu=nokia....@qt-project.org> [mailto:development-bounces+song.7.liu=nokia....@qt-project.org]<mailto:[mailto:development-bounces+song.7.liu=nokia....@qt-project.org]> On Behalf Of ext Markus Goetz Sent: Friday, July 20, 2012 3:32 AM To: development@qt-project.org<mailto:development@qt-project.org> Subject: Re: [Development] About "finish" signal in QHttpNetworkConnectionChannel On 19.07.12 17:55, song.7....@nokia.com<mailto:song.7....@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
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
