> On Mon, 27 Jan 2003, Avi Bryant wrote:
> 
> > If you want to be able to set multiple bindings at once, I would 
> > suggest
> >
> > DynamicContext bindAll: {#foo -> 42} during: [...]
> 
> Stephen, might I also suggest that if you need the feature 
> from RuntimeEnvironments of child processes keeping their 
> parent's dynamic context, rather than special casing it, you 
> do something like this:
> 
> BlockContext>>forkWithDynamicContext
>   |context|
>   context := DynamicContext bindings.
>   ^ [DynamicContext bindAll: context during: self] fork

Part of the problem here is a fundamental issue with how forking
actually works.  In a perfect world, the forked context would point back
to the calling context even though the forked process should never
return to the calling context.  This back pointer should be independent
of the return path that the Process follows and would be used for
finding unwind blocks, exception handlers, and dynamic context (and
dynamic context should probably be used to implement unwind blocks and
exception handlers).

But, to keep this discussion grounded in present realities...I'm
assuming that #bindings would lookup (up the context stack) and flatten
all enclosing bindings into a single dictionary.  I think I might
actually do better if I have a handler at the top of the forked process
that pointed back to the calling context and somehow continued the
lookup there.  Unfortunately, I think I might run into some limitations
of the Exception handling system and may need to use the underlying
primitives directly.

One of the features of RuntimeEnvironments is that you can create a tree
of environments that is maintained independent of any process or stack
(these are instances of SharedRuntimeEnvironment).  Any node in that
tree can then be assigned as the environment for a given process.  If a
process manipulates it's environment, changes are only seen in that
process, however, if you directly access one of your
SharedRuntimeEnvironments, changes are visible to all processes using
that runtime environment (either directly, or indirectly through a
child).  In this way, I can have pools of processes whose dynamic values
for certain variables are always in sync with each other and their
SharedRuntimeEnvironment (unless a given process overrides a variable).

I could possible mimick this with an exception/context stack
implementation if I had a context at the top of each stack that pointed
to a SharedRuntimeEnvironment.  I suppose that if such a context is not
there, I could just default to an image wide default environment.

- Stephen