I think you both didn't realize the subtle problem that I tried to convey.<br><br>Assumption 1: when a thread receives "item added" callback, it doesn't react immediately but only when returning to qt event loop (that's how things work right now), so it doesn't immediately rise refcount on the new item.<br>
Assumption 2: it is possible to playlist_remove a parent and it's child without the parent's pointer to the child being adjusted, because "we don't need the parent anymore" (I am not sure about that)<br>
<br>Under those assumptions the problem is:<br><br>1. We enter a function: int get_teeth_count_of_a_child ( QModelIndex child_index );<br><br>2. We try to get the lock on playlist, but another thread has the lock already. We wait for that thread.<br>
<br>3. The other thread creates a child item, raise it's refcount to 1, adds it to a parent who's pointer is in the <i>child_index</i>, then unrefs both: we had a refcount on the parent but we didn't get opportunity to raise refcount on the child -> the child gets freed, but the parent not, but the parent hasn't had the pointer to the child adjusted, removed, whatever...<br>
<br>4. Then: we get the lock on the playlist, we have a pointer to the parent and have to return data about the child's number of teeth. It doesn't help us to hold a lock! The parent still exists, but the child not, and the parent's pointer to the child is not valid! we dereference the pointer -> bang! segfault! isn't it so?? or if we are very very lucky we might get away without the segfault, only corrupted data, but I wouldn't count on that one :)<br>