[Interest] QThreadPool functionality for QThreads

Frank Rueter | OHUfx frank at ohufx.com
Wed Jan 18 21:37:16 CET 2017


Thanks Elvis.
And my apologies (especially to Thiago) for posting a misleading and 
incopmlete question.

I have been playing with converting to QRunner which seems to work fine 
(haven't tested it thoroughly though).
I will have a look at QNetworkAccessManager so I can compare the 
approaches, thanks for the tip.

Cheers,
frank

On 19/01/17 8:12 AM, Elvis Stansvik wrote:
> 2017-01-18 20:11 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
>> 2017-01-18 20:04 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
>>> 2017-01-18 8:17 GMT+01:00 Frank Rueter | OHUfx <frank at ohufx.com>:
>>>> Hi Thiago,
>>>>
>>>> thanks for your quick reply. I will try and give some more context:
>>>> I use the python requests module inside my PySide app to post requests to a
>>>> website. Some of those requests return a lot of data that I need to parse to
>>>> be able to show progress, other requests are file downloads that I need
>>>> progress bars for as they stream onto disk.
>>>> I had tried to not use threads and use QApplication.processEvents() for each
>>>> data chunk downloaded, but that made the download about 4-5 times slower.
>>>> Introducing threading made a huge difference.
>>> Right, you won't get a good result with that approach. It's always
>>> good to be up front with any special circumstances like this (using a
>>> networking API that does not run on top of the Qt event loop).
>>>
>>>> My app can download a list of files at the same time. Depending on the
>>>> situation and the user request, the list of files to be downloaded can
>>>> happen asynchronously, in other situations they need to be downloaded one
>>>> after the other.
>>> I think this is what confused Thiago: What you mean is sequential (as
>>> opposed to parallell), not synchronous.
>>>
>>> If you have one QThread that depends on the completion of another,
>>> then no, I don't think there's a convenient API in Qt to express that
>>> relationship and run the threads infrom sequence. You'll have to string
>>> them together yourself, or maybe use something else like Threadweaver.
>>> I could be wrong of course :)
>> Another approach is of course to ditch the threading and use the
>> asyncronous QNetworkAccessManager from Qt, instead of using the Python
>> requests module. You can use the downloadProgress/uploadProgress of
> downloadProgress/uploadProgress *signals*.
>
>> the QNetworkReply you get from get(..) or post(..) if you want to show
>> progress (haven't used it myself).
>>
>> Elvis
>>
>>> Elvis
>>>
>>>>>> All I can tell you is that you don't need to do what you're trying to do,
>>>>>> since you don't need threads in the first place.
>>>> If I can avoid threads to do the above I would be more than happy to adjust
>>>> and get rid of them again, but I haven't managed to find a non-threaded
>>>> approach that doesn't slow down the download significantly.
>>>>
>>>> Cheers,
>>>> frank
>>>>
>>>>
>>>> On 18/01/17 6:26 PM, Thiago Macieira wrote:
>>>>> On quarta-feira, 18 de janeiro de 2017 17:21:46 PST Frank Rueter | OHUfx
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I got another threading question for the pros out there:
>>>>>>
>>>>>> In  my current application I am using QThread objects and
>>>>>> QObject.moveToThread() to enable my GUI to download multiple files while
>>>>>> updating progress bars in the main event loop. This is the respective
>>>>> As usual, the usual disclaimer: you do not need threads to do networking
>>>>> or
>>>>> file I/O. The combined overhead of the networking I/O and saving of the
>>>>> files is
>>>>> unlikely to overwhelm the event loop to the point that the progress bar
>>>>> can't
>>>>> update smoothly.
>>>>>
>>>>> I'm not saying impossible, but it's unlikely.
>>>>>
>>>>>> snippet of code:
>>>>>>            self.worker = MyClass()
>>>>>>            self.workerThread = QtCore.QThread()
>>>>>>            self.worker.moveToThread(self.workerThread)
>>>>>>
>>>>>> The trouble is when the user wants to download multiple files at once.
>>>>>> In my current implementation that all works fine and I see multiple
>>>>>> progress bars do there thing.
>>>>>> However, there are cases when I need to force the download threads to be
>>>>>> synchronous. I had hoped that I can use QThreadPool with QThreads, but
>>>>>> turns out I need QRunnables in this case, and those don't have the same
>>>>>> signals as QThread.
>>>>> Why do you need to force them to be synchronous? And synchronous with
>>>>> what?
>>>>> With each other? Or do you mean sync() in the file saving?
>>>>>
>>>>> Finally, what does being synchronous have to do with signals?
>>>>>
>>>>>> So my question is:
>>>>>> Is there a good way to use QThreads in a queue which is controlled by
>>>>>> the main thread, or should I re-write my code and subclass QRunnable to
>>>>>> add the signals I need (i.e. the ones that QThread has by default)?
>>>>> The whole point of QThread is that the code it runs is independent of
>>>>> anything
>>>>> else. Only the OS scheduler decides when it's time to run it or suspend
>>>>> it.
>>>>>
>>>>>> In the latter case I guess I'd have to inherit from both QObject and
>>>>>> QRunnable, is this ok?
>>>>> Right.
>>>>>
>>>>> But we still don't understand what you're trying to do. All I can tell you
>>>>> is
>>>>> that you don't need to do what you're trying to do, since you don't need
>>>>> threads in the first place.
>>>>>
>>>> _______________________________________________
>>>> Interest mailing list
>>>> Interest at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/interest




More information about the Interest mailing list