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 <elvst...@gmail.com>:
2017-01-18 20:04 GMT+01:00 Elvis Stansvik <elvst...@gmail.com>:
2017-01-18 8:17 GMT+01:00 Frank Rueter | OHUfx <fr...@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
