Deadlock with BlockingQueuedConnection on Exit
-
I'm running into (occasional) deadlocks in a QWidget program that uses a BlockingQueuedConnection. There is a slow worker task on a side thread that communicates to the main thread through a signal/slot created with BlockingQueuedConnection. The application also, importantly, has a measurably slow shut down time (it has to write a large amount of data to disk) and a call to quit and wait on the worker thread on exit in a widget's destructor. The deadlock occurs if the worker thread is running when the user exits the program, and the worker subsequently completes and signals the BlockingQueuedConnection before the main thread calls quit and wait. This is because the main thread will not process the BlockingQueuedConnection slot received during the widget's destruction.
I've tried working around this by calling disconnect() on the worker at the start of the Widget's destruction, but it seems like a deadlock could still occur if the worker signals in the brief time before disconnect() is called during destruction.
Is there a better solution to this problem? Is there a way to signal the worker to quit waiting on the BlockingQueuedConnection? Thank you!
-
I'm running into (occasional) deadlocks in a QWidget program that uses a BlockingQueuedConnection. There is a slow worker task on a side thread that communicates to the main thread through a signal/slot created with BlockingQueuedConnection. The application also, importantly, has a measurably slow shut down time (it has to write a large amount of data to disk) and a call to quit and wait on the worker thread on exit in a widget's destructor. The deadlock occurs if the worker thread is running when the user exits the program, and the worker subsequently completes and signals the BlockingQueuedConnection before the main thread calls quit and wait. This is because the main thread will not process the BlockingQueuedConnection slot received during the widget's destruction.
I've tried working around this by calling disconnect() on the worker at the start of the Widget's destruction, but it seems like a deadlock could still occur if the worker signals in the brief time before disconnect() is called during destruction.
Is there a better solution to this problem? Is there a way to signal the worker to quit waiting on the BlockingQueuedConnection? Thank you!
@bobthebuilder
I'm afraid this is way beyond my pay grade, but does https://stackoverflow.com/questions/16741432/qt-signal-slot-multithreading-deadlocks and the proposed answer there shed any useful light on your situation? -
Hi,
Can you explain the need of
BlockingQueuedConnectionin your case ?
