Hi Luc, On 7 July 2017 at 14:25, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: > On Fri, Jul 7, 2017 at 3:18 PM, Dibyendu Majumdar > <mobile@xxxxxxxxxxxxxxx> wrote: >> 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. Yes realize that - so the lock here is only a concept. It is not a mutex or anything like that. > > Otherwise, it's quite similar to Chris' idea of using a refcount. > But then, we 'just' have to correctly maintain this refcount. > Agree that if refcount is used as a lock to prevent inner loops from amending the list then it is the same. But I think Chris is trying to do more - i.e. allow an inner loop to amend the list. That might simply not be possible to handle safely. 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
