On Thu, Mar 20, 2008 at 12:27 AM, Dan Searle <dan@adelix.com> wrote:
> > I had to fiddle about with switching memory contexts rather a lot to > make it work this far, but I'm only guessing as to when it's appropriate > to call MemoryContextSwitchTo(), and to which context to switch to
Here is what I know. Not sure whether it would answer your question though.
A memory context is a memory enclosure with a life associated to it. Whenever the context is freed, all objects allocated in that context are also automatically freed. If there are any references to these objects, they will turn into dangling pointers, causing segfaults and/or memory corruption. So you need to be careful while choosing a memory context to allocate memory from. You don't want to allocate something in a long-lived context if you don't need it for that much time because failure to explicitely free the allocation will result in memory consumption when its not required or even a memory leak. OTOH you don't want to allocate something in a very short-live context, if you may require that object outside the scope of that context.
Certain memory contexts are well known. For example, a TopMemoryContext has life of the session. Any object allocated in this context would remain valid for the entire session. Of course, failure to free them would result in memory leaks.
TopTransactionContext, as the name suggests, is valid in the current top transaction. As soon as the transaction commits/aborts, the context is freed.
CurrentTransactionContext, which may be same as TopTransactionContext remains valid for the current transaction or subtransaction.
Apart from that, there are contexts attached to different objects during execution and their lifespan is usually attached to the lifespan of the object itself. You may need to choose one of them if you know that what you are allocating can not or should not outlive that object.
