Threaded HTTP inside QNetworkAccessManager

Hi, My name is Markus and this is my first blog post on labs :-)

Since some time ago we integrated a change into QNetworkAccessManager that makes HTTP requests run in a separate thread.
Someone asked for clarification on that, so here it goes :)

The reason behind this was the way QtWebKit (based on WebKit1) works. A web browser typically has a lot of work to do.
It needs to parse HTML and CSS, it needs to decode images from JPEG or PNG to something that can be displayed,
it needs to layout the page, it needs to react to user input and it needs to run all the Javascript we have in the nice world of Web 2.0 (Or are we at 3.0 already?)

While all this work is happening the network processing is not progressing if it is happening in the same thread as the rest
of the browser. What we have seen from network traces is that what we call "synchronization points" is happening: While
QtWebKit is busy in the main thread and blocking its event loop, no new network requests are sent out. In really bad cases the HTTP servers stop sending new data. This is especially relevant where you have lower processing power and higher network latency than on the classic desktop PC (Hello mobile device world!).

There are several solutions for this:

1. Put QtWebKit in a thread, leave networking in user thread
2. Put the whole QNetworkAccessManager in a thread
3. Put the HTTP code of QNetworkAccessManager in a thread

What we have done is 3.
Technically this works by putting another layer inside QNetworkAccessManager. The actual HTTP protocol code does not change at all, only the way how QNetworkAccessManager is using it. Also your code and QtWebKit's code do not need to change. This means from Qt 4.8 on you get those benefits without needing to enable anything special.

If you want to use it already now please take a look at our earth team repository and make sure to report bugs :)
If you want to take a look at the code, one relevant new (internal) class is the QHttpThreadDelegate (which lives in the HTTP thread) and controls the HTTP code. It is directed by the (internal) QNetworkAccessHttpBackend (which lives in the user thread) via signals and slots.

PS: A lot of things are happening inside Qt these days and will continue to happen, even though rumor on the streets says otherwise... While you read this we are making the whole QtWebKit experience even more asynchronous with WebKit2 power! :)