<div class="gmail_quote">On Thu, Aug 13, 2009 at 6:30 PM, Jakob Leben <span dir="ltr"><<a href="mailto:jakob.leben@gmail.com">jakob.leben@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div id=":yo" class="ii gt">My idea was to not have another hierarchy for the Qt4 model at all, to really just use p_playlist_t and p_playlist_item_t.<br>We would use<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">

QModelIndex index = createIndex (row, 0, <i>(playlist_item_t *)</i> item);<br></blockquote><br>Then for example:<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">

int rowCount( QModelIndex index)<br>{<br>    return static_cast<playlist_item_t*>( index.internalPointer() )->i_children;<br>}</blockquote></div></blockquote></div><br>I see a big problem here that I just can't see a solution to:<br>
<br>Suppose we hand out playlist_item_t * in a QModelIndex to a Qt view. It might happen that another thread messes with the data of the playlist_item_t before the view uses that QModelIndex, that is before the view calls a function with it as an argument, so that the function could lock the playlist. Basically there is time between handing out a QModelIndex and it being used when the thread which handed out the QModelIndex doesn't hold the playlist lock.<br>
<br>Now if the other thread simply deleted some items and we have reference counting, our pointers to them would still be valid. But imagine that in the time when we don't hold the lock the other thread adds a child to the playlist item, so changes it's pp_children field, but then unreferences both the item and its new child, before we could add a reference to the child! The former item will still exist as we had a reference to it, but with wrong reference to a child that got already deleted, as we didn't add a reference for it.<br>
<br>The whole problem is that we don't control the qt view's code that obtains the QModelIndex, so we can't hold a lock for the whole time when that QModelIndex exists.<br><br>Any idea?<br>