Difference between revisions of "Uno/Article/Working with Environments, Mappings & Objects"

Revision as of 09:59, 2 August 2006

Working with Environments&Mappings

Environments and mappings are at the heart of Uno. Understanding their relationship and how to use them is fundamental for understanding how Uno can integrate different programming languages or how Uno can abstract particular characteristics, e.g. as thread-unsafeness.

Environments

Environments are at the fundament of Uno. Environments allow

• to manage a set of objects, typically sharing some characteristics as the ABI or the "purpose",
• to control the life cycle of any particular object belonging to an environment.

Examples for environments are:

"uno"
"gcc3" 
"uno:unsafe"
"jni:affine"

The part in front of the colon being the ABI, and the part behind it being the purpose (note: purposes may be chained, e.g. "<ABI>:unsafe:debug").

Every environment is process wide unique and global. Requesting a particular environment (e.g. "uno:unsafe") multiple times, always returns the same instance. Instances of environments may control some global state, e.g. mutex or contexts etc., therefor environments can be entered respectively invoked.

While their is no difference in the API, we differentiate environments to either be

• ABI environments, or to be
• purpose environments.

ABI Environments

ABI environments do not control any state and are solely managing objects of their particular ABI.

Purpose Environments

Purpose environments typically only manage objects of the UNO ABI, but do control state.

Entering Environments

Environments may be entered either directly e.g. by calling enter, or indirectly by calling invoke. Not all environments are directly enterable, but all are invokable, semantics might differ slightly.

As only purpose environments control any state, their is actually no difference between entering two environments with different ABIs but with the same purpose:

  "gcc3:unsafe"
  "uno:unsafe"

Consequently, entering a "pure" ABI environment, such as "gcc3", has no effect at all.

Manipulating Objects

Direct manipulation (e.g. casting and calling it) of an object of a particular environment must only be done, while the owning environment has been entered. In contrast, indirect manipulation through the owning environment is guaranteed to always be safe.

Objects of different environments, even if providing the same ABI, must never be mixed, otherwise environment integrity may break (e.g. leading to a thread-safe object providing a thread-unsafe object to multiple threads).

Mappings

Mappings connect any two particular environments in a way, that an object of one environment may be "mapped" to another environment, actually providing a representation of the source object in terms of the destination environment.

A mapping may not only be direct, but may very well be composed of multiple "smaller" mappings. See the cascaded mapping specification for details.