I want to design a single base class for both controlling the thread and executing slots of the class in thread itself via qobject::connect or invokemethod.
When start is called, I call this->movetothread(memthread) and memthread->start to move this into member thread's context and start the eventloop.
when stop is called, qthread's quit is called to stop the event loop. Problem is that, when thread quits, it is impossible to deallocate "this" via deletelater later on since deletelater needs a running eventloop to delete the object. Object's thread context could already be stopped via call to quit before.
I can't connect object->deletelater to thread::finished since object would be unusuable then and I can't start/stop thread again. My aim in the design is to accomplish this actually. Being able to stop the thread, start later, stop again and so on.
I'm not sure if the design is doable with the way qt is but want to at least try.
P.S. My first question, please kindly let me know about any mistakes.
I am not sure I understand the question completely, and also there are very few details. However, why stopping the thread in the first place? Anyway, depending on the specific context, you could start the thread when you want to delete your object and then delete it, then stop the thread and delete the QThread. Otherwise you could simply delete your object. Anther option is to move your object to the main thread when stopping your thread:
QMetaObject::invokeMethod(this, [this] {
moveToThread(qApp->thread());
});
and then simply deleteLater() when you feel you are ready. These are two options, but I think there are others, it depends on your context.
Related
I wish to pass an object using the signal/slot mechanism between threads in Qt. Since I will be passing a pointer to the object, is it safe to call the methods on the object on the receiver's side?
According to this question question the object is not copied (so using original object).
Is this safe? Or am I executing methods on an object belonging to one thread in another thread? Is there a better way to do this?
(I have approximately 20 getters in this class so I don't want to pass individual variables, as well some of the variables are in fact pointers to objects as well)
It is not necessarily safe - signals and slots can be used to cross thread boundaries, so it's possible you could end up trying to access the object from another thread.
The thread in which the slot will be called is determined by the connection type. See the documentation, but as an example:
connect(source, SIGNAL(mySignal(QObject*)), destination, SLOT(mySlot(QObject*)), Qt::DirectConnection);
In this case the function mySlot() will be called from the same thread that the mySignal() signal was emitted in. If your object is not accessed from any threads other than the same thread as the signal emitter this would work fine.
connect(source, SIGNAL(mySignal(QObject*)), destination, SLOT(mySlot(QObject*)), Qt::QueuedConnection);
In this case the function mySlot() will be queued, and called by the event loop of the destination object. So anything done to the object, would happen from within the thread running the event loop of the destination.
I personally find it's best to just stick to passing simple values as arguments. Even though this can work, you would need to add suitable multithreading guards to your QObject if it's likely to be accessed from multiple threads.
First of all, try to use QtConcurrent when you are developing a multi-threaded application. The QtConcurrent namespace provides high-level APIs that make it possible to write multi-threaded programs without using low-level threading primitives such as mutexes, read-write locks, wait conditions, or semaphores.
After that, safety depends on your class members. If all members are thread-safe, then all will be run safely.
Does .ConfigureAwait(false) always use the thread pool and not the UI thread
or is just a hint?
This is a question that has bugged me and I haven't heard a definitive answer.
So is it possible even if you do a .ConfigureAwait(false) block the main UI thread and when debugging the dreaded
Skipped 100 frames!!
message?
Using .ConfigureAwait(false) means when that task ends, the following code will not be marshaled back to the calling thread, saving some thread marshalling, which takes time. When .ConfigureAwait(false) is not called the default is .ConfigureAwait(true) which means "When this task is done, marshal the following code back to the thread this task was called from.
As a general rule, every piece of code that is not in a view model and/or that does not need to go back on the main thread should use ConfigureAwait false.
This is simple, easy and can improve the performance of an application by freeing the UI thread for a little longer.
It is not only a matter or performance but also a matter of avoiding potential deadlocks.
you could read this document
So I have been using QtConcurrent::run for some time and its fantastic. But now I need the function to return an object. Therefore I use the pseudo code
QFutureWatcher<MyObject> fw;
QFuture<MyObject> t1 = QtConcurrent::run(&thOb, &MythreadObjFunc::getList, ConSettings, form, query);
fw.setFuture(t1);
// Both .results() and waitForFinished() block
fw.waitForFinished();
MyObject entries = t1.result();
Then I iterate through the myObject. The issue is that this is blocking e.g. my main GUI is not responsive. And this was the whole reason I started using QtConcurrent::run
Therefore, what is the recommended way to have my GUI execute a QtConcurrent::run and get the object back but not block? I thought of signals and slots where the signal would be from the QtConcurrent::run but this would mean that it would be from a different thread and I read thats not recommended.
Thanks for your time.
You should never use any waitForFinished functions in the GUI thread. Instead, connect a slot to the future watcher's finished signal. See this answer for an example.
From QtConcurrent::run() you can't emit any signal. Runnable function is not a QObject. That is the first thing.
The other thing is that QFutureWatcher::waitForFinished() blocks the execution until the thread ends its execution. This is the intended behaviour. If you have to wait for your function to finish, why do you even launch it on separate thread? It makes no sense.
The easiest solution would be to make your function a member of QObject-inherited class, move the instance to the other thread, launch the calculations and emit done() signal. Qt's signal and slot system is thread-safe and it is the perfect way to use it. There is a outstanding documentation provided by Qt that covers this subject more than enough. You should start reading here: http://qt-project.org/doc/qt-4.8/threads.html
I have an AIR/Flex app I made, I have a few people testing it and everyone is reporting that after leaving it running for a while, it is making all there machines run very slow. It runs fine at first so this must be a memory leak somewhere. I used the profiler on this and the only thing that shows as using a substantial amount of memory is MethodQueueElement which is not a class I wrote, and I have no idea what it does, I am assuming its part of the Flex framework. I am not familiar with using a profiler so I am not sure what all I shuld be looking at, that was the only class that was high on "memory" and it said it had over 100,000 instances. If this is my problem what can I do to fix it? I do not even know what this class does or anything about how it gets instantiated.
Thanks
The MethodQueueElement class is an internal class of the mx.core.UIComponent class.
It is used to represent on method call that has been enqueued by a callLater call.
The callLater method is part of the public interface of UIComponent, so either you call it in your code, or it is beeing called by the framework (as it happens in UIComponent.setFocus e.g.)
To free all MethodQueueElement instances, UIComponent replaces the current array of MethodQueueElements by a new (empty) one. (in the callLaterDispatcher2 method) So the only way to make a memory leak out of it is, to prevent callLaterDispatcher2 from beeing called.
To debug this, you can start to set breakpoints (while you app is running) in the methods callLater (here your instances get created, so somehow it gets called all the time, look at the stacktrace here!), callLaterDispatcher2 (i suppose it wont get called), and check whether UIComponentGlobals.callLaterSuspendCount is != 0, which could be the reason callLaterDispatcher2 doesn't get called.
Should the latter be the case, i suspect, that you have tweens or something else calling UIComponent.suspendBackgroundProcessing but then not calling resumeBackgroundProcessing (because of an exception terminating the code before reaching the resumeBackgroundProcessing call e.g.)
I'd like to know when my application is idle so that I can preload some content. Is there an event or something similar implemented in PyQt?
(I could also do it with threads, but this feels like being too complicated.)
You have at least two different options, you can use a thread or use a timer. Qt's QThread class provides a priority property that you can set to make it only process when no other threads are running, which includes the GUI thread. The other option is a single shot timer. A QTimer with a timeout of 0 milliseconds puts an event on the back of the event queue so that all events and synchronous functions already active or scheduled will be processed first.
In code, the two options would look like the following:
// (1) use idle thread processing
MyQThreadSubclass idleThread;
idleThread.run(QThread::IdlePriority);
// (2) use QTimer::singleShot
QTimer::singleShot(0, receiver, SLOT(doIdleProcessingChunk));
If you go with the single shot QTimer, be careful how much processing you do as you can still block the Gui. You'd likely want to break it into chunks so that GUI won't start to lag:
// slot
void doIdleProcessingChunk() {
/* ... main processing here ... */
if (chunksRemain())
QTimer::singleShot(0, receiver, SLOT(doIdleProcessingChunk));
}
Obviously, the above is C++ syntax, but to answer with respect to PyQt, use the single shot timer. In Python, the global interpreter lock is basically going to render much of your concurrency pointless if the implementation being called is performed within Python.
You also then have the choice of using Python threads or Qt threads, both are good for different reasons.
Have a look at QAbstractEventDispatcher. But ... I still suggest to use a thread. Reasons:
It will be portable
If you make a mistake in your code, the event loop will be broken -> You app might hang, exit all of a sudden, etc.
While the preloading happens, your app hangs. No events will be processed unless you can preload the content one at a time, they are all very small, loading takes only a few milliseconds, etc.
Use a thread and send a signal to the main thread when the content is ready. It's so much more simple.