Re: [PATCH 2/5] pack-bitmap: tag bitmapped packs with their corresponding MIDX
- From
Taylor Blau <me@ttaylorr.com>
- Date
- Aug 29, 2024, 18:58 UTC
- Message-ID
- <ZtDEy/teamtXMAbn@nand.local>
- In-Reply-To
- <xmqqplpt5wrt.fsf@gitster.g>
On Tue, Aug 27, 2024 at 05:14:14PM -0700, Junio C Hamano wrote:
Show 19 quoted lines
> > diff --git a/midx.c b/midx.c > > index ca98bfd7c6..67e0d64004 100644 > > --- a/midx.c > > +++ b/midx.c > > @@ -496,6 +496,7 @@ int nth_bitmapped_pack(struct repository *r, struct multi_pack_index *m, > > MIDX_CHUNK_BITMAPPED_PACKS_WIDTH * local_pack_int_id + > > sizeof(uint32_t)); > > bp->pack_int_id = pack_int_id; > > + bp->from_midx = m; > > Do multi_pack_index objects live as long as bitmapped_pack objects > that point at them live? If m later goes away without letting the > bitmapped_pack know about it, the borrowed pointer in from_midx > would become dangling, which is not what we want to see. > > "None of these objects are released or relocated while we are > running pack-objects, so once the .from_midx member is assigned > here, it will always be pointing at a valid multi_pack_index object" > is a satisfactory answer, I guess.
Good question, and good answer ;-).
This is only relevant in a read-only path where we're generating a new pack from existing packs and not altering those pack or rewriting / deleting the MIDX attached to them. So I think we're OK here and don't have any lifetime/scope issues.
Thanks, Taylor