Hi Chris, On 7 July 2017 at 10:06, Christopher Li <sparse@xxxxxxxxxxx> wrote: > On Fri, Jul 7, 2017 at 1:28 AM, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: >> > My idea of the ref count will do exactly that when the inner > loop try to delete an entry but outer loop holding the node as well. > It will increase the deleted count and replace the ptr entry to > NULL. > > When the ref count of the node drop to zero and node has delete count. > Pack the entry[] array, remove NULL entry and even possible delete > the node as well. > > Let me know if you see any problem with that approach. > How will the insertion scenario be handled - or even splits caused by insertion? These would also invalidate the order of the entries in a ptr list node, right? I think that maybe an alternative approach is to use a lock, and ensure that the ptr list node is locked while it is being iterated. Only lock holder can modify. Any inner loop will fail if it tries to modify the node. The lock can be a pointer - so if NULL unlocked, else locked. Using a pointer as lock allows concept of ownership. But anyway this is only to catch scenarios where the list is being changed by an inner loop. Regards Dibyendu -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
