[Qt-interest] Concurrent qnetworkrequest's to same domain

[Marcus Williams]

Thiago Macieira wrote:
> Which thread did you write this in? m_netManager = new
> QNetworkAccessManager;
>
> The creation of QNetworkAccessManager and the use of all its replies
> must happen in the same thread. You can move the manager, but only if
> it
has just
> been created (no replies running).

Ah ok - the QNetworkAccessManager is created in the download thread (so
in the same thread that is kicking off the requests). If I was to have
multiple QNAMs they would all be kicked off inside this thread so I
would maintain a QList<QNetworkAccessManager*> and rotate through them
with my requests perhaps.

>> Is the max connection limit hackable if we build qt from scratch
>> (we do this already, so if its a simple change this might be the
>> easiest).
>
> Yes, it is. In Qt 4.6, you can change the value from 6 to anything
> you
want.

ok, thats good to know if we need it.

> We still haven't decided whether allowing fine-tuning is a feature
> we  want.
> Instead, I prefer the "bypass the limit" high-priority request.
>
> Of course, if you have 6 high-priority requests running, no  normal-priority
> requests will run.

I quite like this idea, as something I've been wanting to do is bring
requests to the front of the queue (so perhaps you'd be able to
reprioritise a request whilst its in the queue). So I have a dialog with
a list of say 30 buttons, these buttons kick off a request for a
thumbnail from the server. This works well with the slot/signals
changing the icon as it becomes available, but if the user changes the
set of buttons so that maybe a subset of the buttons are displayed (the
buttons may represent a list of search results and the user may refine
their query somehow so only a subset gets displayed) I'd like to be able
to reprioritise those requests so that the thumbnails for the subset get
downloaded first somehow.

Currently I have to abort all the current requests and start new request
off, this has the disadvantage of not continuing to download (and
therefore cache) the other thumbnails for when the user goes back to the
original superset of results.

> I have now changed my opinion to being that a download is a  low-priority and
> usually confined to the background anyway. So it doesn't matter that
it takes
> 20 seconds more for it to start, while the last images of this
> webpage are loaded.

I think this is true in the case of something like a webpage where you
can display some content quickly to a user and background everything
else, updating the page async as the downloads come in. I dont know if
its true in our specific case or not, I'd have to think a bit more :)

> Another feature for low-priority items would be that they can never
use all
> sockets. So a normal-priority request will always get served
immediately if
> there are only low-priority requests processing.

This would be good for our usage as we could kick off downloads of
things in the background like thumbnails the user isnt viewing and still
be able to download things immediately if necessary. Like I said earlier
it would be good to be able to reprioritise requests if necessary and
bring requests to the front of the queue (although this could probably
be achieved with reprioritising).

Thanks

Marcus