PDA

View Full Version : Destruction in separate threads



KevinKnowles
18th March 2012, 17:49
Question 1:

Let’s assume we have two threads (thread1 and thread2), each running their own event loop hosting a single QObject (obj1 and obj2). The signals of the two QObjects are connected to slots on the alternate object, and aside from this signal-slot communication, the two objects do not access each other directly.

Is it safe if obj2 is destroyed, without disconnecting it from obj1 first, while obj1 continues to execute in its own thread?
Is there any way that obj1 might hit some race condition where it sends a signal to obj2 before obj2 can disconnect itself?

Keep in mind: In my hypothetical case, the thread2 message loop is being shut down immediately following the obj2 destruction, so any lingering obj2 messages shouldn’t be a problem (otherwise, I would use deleteLater()).

Question 2:

If a deleteLater signal is put into the message loop, but the message loop is then immediately exit()ed, is the object ever deleted? If it isn’t, is this a bug? It seems that deleteLater’s should always be processed, even if a thread is closing.

I'm a bit new when it comes to QT, so I hope these questions aren't too fundamental. Googling only provides similar information, but nothing confirming either of these two issues. Thanks in advance :)

wysota
18th March 2012, 18:15
Is it safe if obj2 is destroyed, without disconnecting it from obj1 first, while obj1 continues to execute in its own thread?
Yes.

Is there any way that obj1 might hit some race condition where it sends a signal to obj2 before obj2 can disconnect itself?
No.


If a deleteLater signal is put into the message loop, but the message loop is then immediately exit()ed, is the object ever deleted?
Define "immediately".

If it isn’t, is this a bug?
No, deleteLater() needs an event loop.


It seems that deleteLater’s should always be processed, even if a thread is closing.
If the thread exits you should first push the object to an existing thread to be sure its events can still be processed after its thread dies.

KevinKnowles
19th March 2012, 02:52
Define "immediately".

I was thinking about this a bit more, and realized that I had overlooked the parent child relationships. Even if a deleteLater() gets thrown away because the thread is ending, as long as the threads "parent" objects are deleted, they will cascade down and clean up those children on the way out.

I had somehow convinced myself that these "deleteLater" objects would never actually be deleted.

Finally, order is restored to the wonderful world of unmanaged memory :)

-- Thanks again

wysota
19th March 2012, 09:49
Even if a deleteLater() gets thrown away because the thread is ending, as long as the threads "parent" objects are deleted, they will cascade down and clean up those children on the way out.

Objects living in thread A can't be children of QThread object representing thread A. Thus deleting the thread object will not delete objects used by the thread.