
<CHAPTER ID="chapter.limits">
  <TITLE>Limitations and Modifications</TITLE>

<P>The current release has the following limitations
and modifications with respect to the specifications
of the distribution model and the failure model.
A <EM>limitation</EM> is an operation that is specified
but is not possible or has lower performance
in the current release.
A <EM>modification</EM> is an operation that is specified
but behaves differently in the current release.

<P>Most of the limitations and modifications
listed here will be removed in future releases.

<SECTION><TITLE>Performance limitations</TITLE>

<P>These reduce performance but do not affect language semantics.
They can safely be ignored if performance is not an issue.

<list>
<item>The following problems
are related to the <<Remote>> module and virtual sites
(see also <ptr.extern to="ozdoc:system" key="chapter.remote">).
<list>
<item>On some platforms (in particular, Solaris),
the operating system in its default configuration
does not support virtual sites efficiently
(see also <ptr.extern to="ozdoc:system" key="chapter.remote">).
This is due to a system-wide limit
on the number of shared memory pages.
For Solaris,
the default is six shared pages per process and 100 system-wide.
Changing this limit requires rebooting the machine.
Since at least two pages are needed for efficient communication,
the default value results in poor
performance if a site connects to more than three virtual sites.

<item>The Mozart system does its best to reclaim shared
memory identifiers, even upon process crashes, but it is
still possible that some shared memory pages become
unaccounted for and thus stay forever in the operating system.
If this happens please use Unix utilities
to get rid of them.
On Solaris and Linux there are two,
namely <<ipcs>> and <<ipcrm>>.
</list>

<item>The code of functions, procedures, classes, and functors
(but not objects) is always inserted in messages,
even if the code is already present at the destination.
In future releases, the code will be copied
across the network only
if it is not present on the destination site.
In both current and future releases, at most a single copy
of the code can exist per site.

<item>The distributed garbage collection
algorithm reclaims all unused entities
except those forming a reference cycle
that exists on at least two different owner sites
(a <EM>cross-site cycle</EM>).
For example, if two sites each own an object
that references the other,
then they will never be reclaimed.
It is up to the programmer to break the cycle
by updating one of the objects to no longer
reference the other.

<item>If a site crashes that has references to entities created on
other sites, then these entities are not garbage-collected.
Future releases will incorporate a lease-based or similar
technique to recover such entities.

<item>The fault state <<tempFail>> is indicated only after
a long delay.
In future releases, the delay will be very short and
based on adaptive observation of actual network behavior.
</list>

<SECTION><TITLE>Functionality limitations</TITLE>

<P>These affect what operations are available to the programmer.
They document where
the full language specification is not implemented.
We hope that the undergrowth of limitations is sparse
enough to let the flowers of Oz grow unwithered.<NOTE
FOOT>C. A. R. Hoare, <em>The Emperor's Old Clothes</em>,
1980 Turing Award Lecture.</NOTE>

<list>
<item>On Windows, the <<Remote>> module has limited functionality.
Only a single option is possible for <<fork>>, namely <<sh>>.
Future releases will add more options.

<item>The <<Connection>> module does not work correctly
for applications separated by a firewall.
This limitation will be addressed in a future release.

<item>Threads, dictionaries, arrays, and spaces are sited,
even though they are in base modules.
In future releases, it is likely that
dictionaries and arrays will be made unsited.
Threads and spaces will be made stationary entities
that can be called remotely (like ports).

<item>When a reference to a constrained variable
(finite domain, finite set, or free record)
is passed to another site, then this reference
is converted to a <em>future</em>.
The future will be bound when the constrained
variable becomes determined.

<item>If an exception is raised or a handler or watcher
is invoked for an <EM>object</EM>,
then the <<Entity>> argument is undefined.
For handlers and watchers, this limitation can
be bypassed by giving the handler and watcher procedures
a reference to the object.

<item>If an exception is raised or a handler is invoked
for an <EM>object</EM>,
then the attempted object operation cannot be retried.
This limitation can be bypassed by programming the
object so that it is known where in which method
the error was detected.
</list>

<SECTION><TITLE>Modifications</TITLE>

<P>There is currently only one modification.
<list>
<item>A handler installed on a <EM>variable</EM> will retry
the operation (i.e., bind or wait) after it returns.
That is, the handler is inserted before the operation
instead of replacing the operation.
</list>

</CHAPTER>


