Mehmet Yavuz Selim Soyturk wrote: >> - if (cc->from_ctx) >> - Parrot_free_context(interp, cc->from_ctx, 0); > > >> - Parrot_free_context(INTERP, from_ctx, 1); > > > I don't know much about this context stuff, so maybe I don't see > something, but how are those contexts freed after your patch? >
I didn't formally check what happens, but I think this is what continuations are: they store the interpreter state (not mutable values' state), which consists of a code offset, a Parrot_context (like registers and lexpads), and such. So when a continuation is invoked, we restore the interpreter state. This requires among other things a Parrot_context, and we store one in the to_ctx field. We don't need other Parrot_contexts to do the invoke (except maybe the current, for dynamic state reconstructing). Reasoning from this model, I can't see what from_ctx is for. After solving one exception, there is no place that uses the value of from_ctx. So if a piece of code uses that context, it's stored at another place and that place should refcount itself, not delegate that to Parrot_cont->from_ctx. Still, there may be a place that I overlooked and that increases but never decreases the refcount. Then the context should be automatically handled by the mark-and-sweep gc after the patch, so no memory leak should arise. On a side note, Continuation->mark doesn't seem to collect the from_ctx. This means that if some context was kept live only with from_ctx, it would be marked dead on the next gc run. And since that didn't produce bugs, we can also assume that from_ctx is redundant. -- Bram Geron | GPG 0xE7B9E65E
