On Fri, Jul 7, 2017 at 3:18 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > 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. Don't forget that it's not multithreaded code we're talking here: a lock, in itself, won't help since there is no concurrent access. Otherwise, it's quite similar to Chris' idea of using a refcount. But then, we 'just' have to correctly maintain this refcount. -- Luc -- 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
