schollii
13th April 2015, 13:57
I have an app that consists right now of a qgraphicsview and qgraphicsscene, and in it I draw some widgets (converted to qgraphicsitem via the usual proxy method), and some lines between the widgets. The creation of lines are initiated via queued signals from a backend QThread, the drawing is occuring in the main thread.
Every few runs, the app freezes halfway through drawing the lines -- no crashes, or exception raised, just freezes, and Windows shows the "(not responding)" in window title. I have QTimers firing a "heartbeat" every second: one fires in main thread, one in thread that signals for line to be drawn, and one in a do-nothing (other than heartbeat) thread: all three stop firing, indicating all event loops are frozen, so I don't think it is a deadlock (I am not using any mutexes or thread synchro due to use of queued signals). Could it be deadlock due to 2 threads wanting Python's GIL? Any ideas what might be causing this? When the backend stuff runs in main thread, no issues.
I trust that if connection is made between a signal in one thread and a slot in another, Qt automatically choose Qt.QueuedSignal as connection type, so although I know it would cause havoc if lines were being drawn in backend thread, I have not rigorously verified the draw indeed happens, how could it not? But how do you recommend I check this, compare currentThreadId with main thread ID? I can't find where to get the main thread id.
Every few runs, the app freezes halfway through drawing the lines -- no crashes, or exception raised, just freezes, and Windows shows the "(not responding)" in window title. I have QTimers firing a "heartbeat" every second: one fires in main thread, one in thread that signals for line to be drawn, and one in a do-nothing (other than heartbeat) thread: all three stop firing, indicating all event loops are frozen, so I don't think it is a deadlock (I am not using any mutexes or thread synchro due to use of queued signals). Could it be deadlock due to 2 threads wanting Python's GIL? Any ideas what might be causing this? When the backend stuff runs in main thread, no issues.
I trust that if connection is made between a signal in one thread and a slot in another, Qt automatically choose Qt.QueuedSignal as connection type, so although I know it would cause havoc if lines were being drawn in backend thread, I have not rigorously verified the draw indeed happens, how could it not? But how do you recommend I check this, compare currentThreadId with main thread ID? I can't find where to get the main thread id.