[PyQt] Multithreading, signals, reference counting and crash

Phil Thompson phil at riverbankcomputing.com
Fri Feb 12 22:20:48 GMT 2016

On 12 Feb 2016, at 7:57 pm, Jones, Bryan <bjones at ece.msstate.edu> wrote:
> I'd like to thank Ilya for bringing this to light. I thought I'd worked around a similar problem, but I now see that I mistakenly assumed Python semantics where C++ semantics apply. To make sure I understand correctly:
> 1. If a Python type can converted to a pass-by-value C++ type (int, long, etc.) then it will be passed as the C++ value through the signal/slot mechanism, meaning I don't need to retain a Python reference to it to keep it valid.
> 2. If a Python type cannot be converted to a pass-by-value C++ type (string, big int, dict, object, etc.) then a pointer to it will be passed through the signal/slot mechanism, meaning I must retain a Python reference until the signal has been delivered to all slots.
> However, I do see Qt employing pointers (QFileSystemWatcher's signals emit const QString&, QLabel::setMovie(QMovie*). Does this imply that the emitters of these signals can somehow "know" when it's free to destroy the QString they emitted? Or that developers which use QFileSystemWatcher should not destroy it until all of its signals have been delivered? This seems hard to do. How do C++ developers using Qt do this? Perhaps I can learn from their approach.

Remember that the original discussion was in the context of threads and queued connections. For ordinary connections you don't need to worry. If you are using queued connections to pass pointers to objects to another thread then you are much more likely to be doing so under limited conditions. For example your design may mean you know that there will only be one receiver and maybe sender and receiver cooperate on ownership.


More information about the PyQt mailing list