Yes, exactly what I said.
But Patrik's problem is that he cannot stop the thread.
Everything works well ( he starts the event loop and all ), but the thread doesn't ever finish because he wasn't calling exit or quit anywhere.
Not so sure about that. Signals can be emitted from within the thread to other threads - this works because the are nothing but some events. It is similar to calling QApplication: postEvent( someThread, someEvent ).One has to call exec() within run() to start the event loop for the thread so that signals can be emitted.
Yes, any event that targets this thread( without an event loop ) is a potential danger to the entire application ( therefore to other threads ).Without it QHttp or any other class that uses events (signals included) won't function properly
It happened to me - I was trying to create a pixmap( load it from disk ) in some thread that didn't have an event loop. But QPixmapCache( used internally by QPixmap ) sends timer events to the creator thread.
This resulted in the GUI thread's event loop getting compromised ( most of the times stopped processing it's own events ).
I am not sure if you remember it, but it was about the same time when I had problems with that crash in QProgressDialog.
Anyway, to make a long story short ( too late, I guess), signals can be emitted from threads without event handlers but the other way around is not safe at all - actually it won't work( since we're talking about queued connection ).
Good to know that.Please note that this doesn't concern the finished() signal as it is emitted from the parent (where QThread object was created) thread.
Regards




.
Reply With Quote
Bookmarks