In my opinion, our problem situation is as follows:
When terminating the program, Bus instances are destroyed without stopping the threads.
When calling Swift.destroyBus(), since bus.stop() immediately returns and does not guarantee that the thread is stopped at all, the following bus.deleteLater() will be executed before the thread actually stops.
I cannot accept the proposed solution to add wait() as a slot of self._consumer.finished... I have no idea why it works.
The reason is that self._consumer.finished is a signal that I defined, and it will never be emitted unless the stop() is called so the while loop in run() finishes.
However, I've found a very magical phenomenon.
I tested as follows:
Define a new signal QueueConsumer.test().
Connect wait() as a slot to the test signal instead of finished signal.
It also solves the problem! Note that I only defined the signal and never used it, i.e., test signal is never emitted.
In my opinion, our problem situation is as follows:
Bus
instances are destroyed without stopping the threads.Swift.destroyBus()
, sincebus.stop()
immediately returns and does not guarantee that the thread is stopped at all, the followingbus.deleteLater()
will be executed before the thread actually stops.I cannot accept the proposed solution to add
wait()
as a slot ofself._consumer.finished
... I have no idea why it works. The reason is thatself._consumer.finished
is a signal that I defined, and it will never be emitted unless thestop()
is called so the while loop inrun()
finishes.However, I've found a very magical phenomenon. I tested as follows:
QueueConsumer.test()
.wait()
as a slot to thetest
signal instead offinished
signal.test
signal is never emitted.😄 I will study this further...
Originally posted by @kangz12345 in https://github.com/snu-quiqcl/swift/pull/96#issuecomment-1474717462