Where's the latest doc on "the right way" to use QThread?

I've read a lot of posts and tutorials on the "right way" to do QThreads, but it's been a while since I've implemented something that required new code.

I recall some saying doing it this way was wrong, and wrong documentation, but later others saying no, doing it the documented way was OK So, now when I look at examples I wonder if I'm looking at the latest notion of "best practice" for using QThreads.

Is there a place I can find that? Official documentation on how to correctly use QThreads?

Here's a representative blog entry that makes sense to me:

https://mayaposch.wordpress.com/2011...l-explanation/


But it's several years old, and I want to make sure there isn't some later, different consensus.

This article is up to date at all times.

There is no right/wrong approach, since it always depends on the task that the thread is executing.

The so called "right way" of many blogs is the approach that is easiest to get right if the task involves event processing.

Cheers,
_

Quote:

---

This article is up to date at all times.

---

Which article? I don't see a URL in your reply...

---

Added after 10 minutes:

Yes, of course it depends on what you're doing, but I think the consensus on how to do it right given the task involves event processing has evolved.

There was a lot of discussion on whether its necessary or desirable to sublcass QThread, use moveToThread, etc.

My latest need for a QThread is pretty simplistic.

The worker only needs to make a blocking call to a third party api and emit a signal when it returns.

The invocation of the blocking call needs to be initiated from the main thread, but run on the new thread to keep the main thread event loop running. So, there's a slot in the worker to initiate the blocking call. The slot emits a signal when the blocking call returns.

A "wrapper class" creates the worker object and a QThread, then moves the worker object to the QThread.

I'm not sure, buy maybe subclassing of the QThread is necessary to put an exec() in the run function. However, that thread will always either be in the blocking call or just returning, so there might be a different way.






I think it's getting code to run on the worker thread that requires more care, but I just want to make sure I've got it right...

If all you need is to run a function in another thread, then the higher-level QtConcurrent::run() is the perfect tool for the job. It will be much better than rolling out your own QThread-based solution. If you insist on managing the QThread yourself (which is useful in very specific cases), then subclass it since you do not need an event loop: just put your blocking code in the run() method.

Yes, it looks perfect!

Thanks,

"This article" from message opening this thread.

QtConcurrent::run() is nice on first look but make sure you never use that in a library, only in application code.
Like all QtConcurrent functions it is hardcoded to use the global thread pool.

Cheers,
_

So, I need a little more than just running the function in another thread--I need a signal emitted and connected to slot that runs on the main thread when the async function returns.

These are all new classes for me, but it looks like QFuture and QFutureWatcher classes can be used for that.

In my case, the same aysnc function needs to be called again immediately after it returns. The return of the blocking async function indicates a frame is available for processing, so good performance is important.

Is there a lot of overhead instancing a new QFuture and QFutureWatcher every time the async function call needs to be done? Is there a way to use the same instances with multiple invocations of the same async function?

Also, is it ok for the QFuture and QFutureWatcher instances to go out of scope after connecting the isFinished() signal of the QFutureWatcher to a slot in the application code?

If the blocking function needs to be called in a tight loop, then derive from QThread and implement run().

Cheers,
_