<< Prev | - Up - | Next >> |
The current release has the following limitations and modifications with respect to the specifications of the distribution model and the failure model. A limitation is an operation that is specified but is not possible or has lower performance in the current release. A modification is an operation that is specified but behaves differently in the current release.
Most of the limitations and modifications listed here will be removed in future releases.
These reduce performance but do not affect language semantics. They can safely be ignored if performance is not an issue.
The following problems are related to the Remote
module and virtual sites (see also Chapter 12 of ``System Modules'').
On some platforms (in particular, Solaris), the operating system in its default configuration does not support virtual sites efficiently (see also Chapter 12 of ``System Modules''). 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.
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
.
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.
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 cross-site cycle). 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.
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.
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.
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.1
On Windows, the Remote
module has limited functionality. Only a single option is possible for fork
, namely sh
. Future releases will add more options.
The Connection
module does not work correctly for applications separated by a firewall. This limitation will be addressed in a future release.
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).
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 future. The future will be bound when the constrained variable becomes determined.
If an exception is raised or a handler or watcher is invoked for an object, 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.
If an exception is raised or a handler is invoked for an object, 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.
There is currently only one modification.
A handler installed on a variable 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.
<< Prev | - Up - | Next >> |