<div class="gmail_quote">2009/8/14 Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net">remi@remlab.net</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
And what are you suggesting?<br></blockquote></div><br>I have stated my two suggestions: either we always check if the target address of the pointer can be found from the playlist root down, or we always take care to correct playlist_item's internal pointers (which I hope I succeeded to show is not so very common and obvious in practice).<br>
<br>2009/8/14 Rémi Denis-Courmont <span dir="ltr"><<a href="mailto:remi@remlab.net">remi@remlab.net</a>></span><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
Currently, we use playlist item IDs, which are weak handles, which are<br>
buggy. There is a warranty that you won't get a dangling pointer from an<br>
item ID. But if you save the item ID for later retrieval, you may later get<br>
another item (due to ID wrap-around), or no ID at all. In fact, if things<br>
wrap around, hell breaks loose because we may assign the same ID to more<br>
than one item...<br></blockquote>
<br>
That's why I think using the pointers to items directly is cool, because the system takes care itself that a newly allocated memory will never overlap an already allocated one, hence a pointer to an item will point to it and only it as long as the item is not freed. I see pointers as the best handles you can have. Only you have to do reference counting then.<br>
<br>By the way, should it be a parent item who raises reference count on an item when it becomes it's child? or should there be one reference number on every playlist item per interface, per user so to speak or maybe per thread? Or both?<br>