[Qt-interest] qtconcurrent::run() virtual member methods?

[Liam Staskawicz]

Hi Thiago - thanks for the thorough run-down.  The QTimer approach is  
a little unwieldy, but of course is totally manageable.  That will be  
my approach moving forward.

I look forward to the addition of timeout functionality to  
qnetworkaccessmanager someday!  Thanks again.

Liam

On Jun 10, 2009, at 3:14 PM, Thiago Macieira wrote:

> Liam Staskawicz wrote:
>> Hi - I was taking the opportunity of adding timeout functionality  
>> to the
>> QNetworkAccessManager api to experiment with QtConcurrent a bit.   
>> Since
>> there doesn't seem to be a built-in way to specify a timeout per
>> request, I thought I'd run each request in a thread via QtConcurrent
>> and call waitForReadyRead with my appropriate timeout value.  Code
>> looks roughly like:
>
> First of all, don't use threads. You don't need them. You can do this
> without threads.
>
> Second, QNetworkReply does not override waitForReadyRead() from  
> QIODevice.
> Here's what that function does:
>
> bool QIODevice::waitForReadyRead(int msecs)
> {
>    Q_UNUSED(msecs);
>    return false;
> }
>
> Third, even if that function worked, you MUST NOT access QObjects in  
> other
> threads than the thread they have affinity to. In the special case of
> QNetworkReply, you must move ALL replies and the manager into that  
> thread.
> That would defeat your purpose.
>
>> something to do with the fact that waitForReadyRead is provided by
>> QIODevice?  The doc for QtConcurrent::run() is mostly based on a few
>> examples so I wasn't able to glean too much more from it.
>
> That's exactly the reason. This function requires a bit more of  
> template
> black magic to support passing a function that is not defined at the  
> exact
> same class as the object you passed as pointer. It's doable, but  
> starts
> getting very ugly very soon.
>
> By the way, you should have also noticed that waitForReadyRead would  
> not
> work, since it's defined by QIODevice.
>
>> Secondarily, any other better timeout strategies for
>> QNetworkAccessManager would also be welcome!
>
> Yes, QTimer would do just fine. If it fires before finished(), call  
> abort().
> -- 
> Thiago Macieira - thiago.macieira (AT) nokia.com
>  Senior Product Manager - Nokia, Qt Software
>      Sandakerveien 116, NO-0402 Oslo, Norway
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest