Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions
- From
Christian Couder <christian.couder@gmail.com>
- Date
- Oct 29, 2016, 22:06 UTC
- Message-ID
- <CAP8UFD3hNEU_UeVizU6SVJTt4hqJPag9XWqZOM3FKCGJZXOthg@mail.gmail.com>
- In-Reply-To
- <CACsJy8DPt3EJoSTVEZFbH6xXbh78MbLZ4h+50K4eoFxPYSaN=Q@mail.gmail.com>
On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen <pclouds@gmail.com> wrote:
Show 19 quoted lines
> On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
> <christian.couder@gmail.com> wrote:
>> +void remove_split_index(struct index_state *istate)
>> +{
>> + if (istate->split_index) {
>> + /*
>> + * can't discard_split_index(&the_index); because that
>> + * will destroy split_index->base->cache[], which may
>> + * be shared with the_index.cache[]. So yeah we're
>> + * leaking a bit here.
>
> In the context of update-index, this is a one-time thing and leaking
> is tolerable. But because it becomes a library function now, this leak
> can become more serious, I think.
>
> The only other (indirect) caller is read_index_from() so probably not
> bad most of the time (we read at the beginning of a command only).
> sequencer.c may discard and re-read the index many times though,
> leaking could be visible there.So is it enough to check if split_index->base->cache[] is shared with the_index.cache[] and then decide if discard_split_index(&the_index) should be called?
Thanks, Christian.