Avi Bryant <avi at beta4.com> wrote:
> On Wed, 12 Jun 2002, Anthony Hannan wrote:
> > The only functional
> > difference between the old and new MethodContexts is that new contexts
> > know which process they belong to and are assumed to only be in one
> > process stack.
> 
> It was exactly this difference that confused me when I looked at
> implementing call/cc on the block closures image.  I need to be able to
> copy a bunch of MethodContexts, keep them around, and swap them in later -
> possibly into a different process than the one that originally created
> them.  How can this be done with the BC system?

A context can change processes, or be taken out and put in another later, it just can't be in more than one at the same time.
> 
> If you implemented the stack in the VM as you discussed, would this allow
> the MethodContexts to look more like the current ones?

They will look like the old ones but with the above restriction.  I think this restriction is appropriate since if more than one process returns out of a shared context the later one will be trying to return out of a dead context.  This restriction also simplifies contexts manipulation since you can find its process and called contexts (not just senders) easily.  And it fits into the stack model better (which is how I implement it), the old way is the linked list model which leads to trees/branches instead of just stacks.
	But if this restriction is really inappropriate I will remove it and work around it.

Cheers,
Anthony