Tomas Vondra <tv(at)fuzzy(dot)cz> writes: > i.e. either destroy the whole context if possible, and just free the > memory when using a shared memory context. But I'm afraid this would > penalize the shared memory context, because that's intended for cases > where all the build states coexist in parallel and then at some point > are all converted into a result and thrown away. Adding pfree() calls is > no improvement here, and just wastes cycles.
FWIW, I quite dislike the terminology "shared memory context", because it sounds too much like it means "a context in shared memory". I see that the patch itself doesn't use that phrase, which is good, but can we come up with some other phrase for talking about it?