Re: [PATCH 1/5] do not corrupt ptrlist while killing unreachable BBs

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Fri, Jul 7, 2017 at 3:18 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Hi Chris,
>
> On 7 July 2017 at 10:06, Christopher Li <sparse@chrisli.org> wrote:
>> On Fri, Jul 7, 2017 at 1:28 AM, Luc Van Oostenryck
>> <luc.vanoostenryck@gmail.com> 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