Re: [RFC PATCH 1/2] reftable: remove the "return_block" abstraction

[Junio C Hamano <gitster@pobox.com>]

Han-Wen Nienhuys <hanwen@google.com> writes:

> On Fri, Apr 15, 2022 at 12:21 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>>
>> This abstraction added in 1214aa841bc (reftable: add blocksource, an
>> abstraction for random access reads, 2021-10-07) has the caller
>> provide a "blockp->data", so there's not point in having the vtable
>> have a custom free() function.
>>
>> In addition this had what looked like a poor man's SANITIZE=address
>> doing a memset() to 0xff just before the data was free'd.
>
>>  void reftable_block_done(struct reftable_block *blockp)
>>  {
>> -       struct reftable_block_source source = blockp->source;
>> -       if (blockp && source.ops)
>> -               source.ops->return_block(source.arg, blockp);
>> +       FREE_AND_NULL(blockp->data);
>
>
> My thinking here is that we could mmap the reftable file to do reads.
> In that case, discarding the block would imply decreasing a refcount
> somewhere, rather than deallocating memory.

Sounds like a plan.  As a solution to the memset() thing, ripping
out this abstraction layer is indeed not just overkill but also
doing too much of "while we are at it".

Let's take what we've queued on cm/reftable-0-length-memset and
merge it down.

Thanks.