From: Han-Wen Nienhuys <hanwen@google.com>
Date: Mon, 25 Apr 2022 09:57:38 GMT
Subject: Re: [RFC PATCH 1/2] reftable: remove the "return_block" abstraction
Message-ID: <CAFQ2z_O7ytx=AsXuJbYnOdMwT0u03sMP-ZjRRjt4HFn48HT-2g@mail.gmail.com>
In-Reply-To: <RFC-patch-1.2-76ed86bf88c-20220415T101740Z-avarab@gmail.com>

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.

-- 
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.