<div dir="ltr">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:<div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Bryan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 3:43 AM, Phil Thompson <span dir="ltr"><<a href="mailto:phil@riverbankcomputing.com" target="_blank">phil@riverbankcomputing.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11 Feb 2016, at 7:15 pm, Ilya Kulakov <<a href="mailto:kulakov.ilya@gmail.com">kulakov.ilya@gmail.com</a>> wrote:<br>
><br>
> Phil,<br>
><br>
</span><span class="">> How does Qt's automatic unsubscribing in QObject's destructor works then?<br>
><br>
> Best Regards<br>
> Ilya Kulakov<br>
<br>
</span>Unsubscribing to what?<br>
<br>
Qt maintains lots of internal data structures about connections, but these aren't exposed. As far as I know Qt does not track pointers to QObjects when they are sitting in a thread's event queue.<br>
<span class="HOEnZb"><font color="#888888"><br>
Phil<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>> On 12 февр. 2016 г., at 0:30, Phil Thompson <<a href="mailto:phil@riverbankcomputing.com">phil@riverbankcomputing.com</a>> wrote:<br>
>><br>
>><br>
>>> On 11 Feb 2016, at 6:16 pm, Ilya Kulakov <<a href="mailto:kulakov.ilya@gmail.com">kulakov.ilya@gmail.com</a>> wrote:<br>
>>><br>
>>> Phil,<br>
>>><br>
>>> I said I don't know all the details :)<br>
>>><br>
>>> PyQt "controls" both signals and slots. Doesn't it know how many receivers are there before it sends?<br>
>><br>
>> The short answer to the question is no. Also, with queued connections, a signal may be sitting in an unprocessed event queue for an indeterminate amount of time. In network terms, signals are UDP, not TCP.<br>
>><br>
>> Phil<br>
><br>
<br>
_______________________________________________<br>
PyQt mailing list    <a href="mailto:PyQt@riverbankcomputing.com">PyQt@riverbankcomputing.com</a><br>
<a href="https://www.riverbankcomputing.com/mailman/listinfo/pyqt" rel="noreferrer" target="_blank">https://www.riverbankcomputing.com/mailman/listinfo/pyqt</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Bryan A. Jones, Ph.D.<br>Associate Professor<br>Department of Electrical and Computer Engineering<br>231 Simrall / PO Box 9571<br>Mississippi State University<br>Mississippi state, MS 39762<br><a href="http://www.ece.msstate.edu/~bjones" target="_blank">http://www.ece.msstate.edu/~bjones</a><br>bjones AT ece DOT msstate DOT edu<br>voice 662-325-3149<br>fax 662-325-2298<br><br>Our Master, Jesus Christ, is on his way. He'll show up right on<br>time, his arrival guaranteed by the Blessed and Undisputed Ruler,<br>High King, High God.<br>- 1 Tim. 6:14b-15 (The Message)<br></div>
</div>