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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 25, 2022, 17:30 UTC
Message-ID: <xmqqilqxvzoa.fsf@gitster.g>
In-Reply-To: <CAFQ2z_O7ytx=AsXuJbYnOdMwT0u03sMP-ZjRRjt4HFn48HT-2g@mail.gmail.com>

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

Show 22 quoted lines

> 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.