Thread (39 messages) flat view 39 messages, 3 authors, 2016-11-09

Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions

From: Christian Couder <hidden>
Date: 2016-10-29 22:06:37

On Tue, Oct 25, 2016 at 11:58 AM, Duy Nguyen [off-list ref] wrote:
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
[off-list ref] wrote:
quoted
+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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help