Changes for Release 0.1.5
- New Nameservice: A few changes to the namservice interface
have been made and a new implementation has been added:
- Thomas the Dane has provided a "subnet" implementation
(osl.nameservice.subnet) which takes advantage of IP broadcast to
streamline name propagation during migration. The performance of his
implementation is much improved over that of the "default"
(osl.nameservice.default).
- The nsInitialize method (osl.nameservice.NameService) no
only requires a Scheduler argument. This change was made
because the "subnet" implementation uses its own transport layer
(which is not defined as an implementation in osl.transport) and
therefore doesn't require a transport layer argument.
- Actor Contexts and Streams: There are a few minor changes
in the Actor class (osl.manager.Actor) which should not affect
existing programs unless they are executed with a security manager.
Also, the notion of an "actor context" has been added and is currently
used for propagating "standard streams" to new actors during creation:
- Every ActorCreateRequest now includes an
ActorContext. An actor "context" consists of information
that represents the environment in which a user-written actor
resides. Currently, this information consists of the names of the
standard stream actors which a local actor may use to display output
or read input from the user. Note that context information is meant
to be useful to instances of Actor, rather than
ActorImpl. Instances of ActorImpl which need to
exchange information at creation time may do so through the use of
request tags (see below).
- The tag interface which was previously a part of the
ActorMsgRequest class (e.g. ActorMsgRequest.addTag) has been
moved into the ActorRequest class so that any actor request
may include tag information. This provides a convenient mechanisms
for exchaning information between instances of ActorImpl in a
manner which is transparent to the underlying user-written actors.
- This release of the foundry includes a standard I/O interface
which is meant to mimic stdin, stdout and stderr in C. In particular,
the StreamInputActor interface defines the behavior of an
actor which handles an input stream. Similarly, the
StreamOutputActor interface defines the behavior of an actor
which handles an output stream. External actors may use these
interfaces to gather input or display output using "send" and "call"
(as opposed to using System.in, System.out and
System.err directly). The Actor fields:
Actor.stdin, Actor.stdout and Actor.stderr
give the addresses of local stream handler actors. See the
osl.examples.helloworld package for an example using these
standard streams.
- New Shell Features: The following shell features have been
added:
- The shell service has been adapted to work with streams and
contexts as described above. When a new shell service session is
opened, the first response from the shell consists of three port
numbers. These port numbers are for stdin, stdout and stderr sockets
respectively. The external client of the session may open a
connection to these sockets in order to read output or provide input.
In particular, the shell actor associated with a session has a context
which sets stdin to the stdin port, stdout to the stdout port and
stderr to the stderr port. This context is propagated to all actors
created by the shell (as long as the implementation of the new actors
is an instance of BasicActorImpl). In short, this means that
any output generated by an actor will appear on the stdout socket, any
input will be read from the stdin socket, and any error output will
appear on the stderr socket.
- The "create" command in the shell service has been changed to
require a location as the first argument. The "service" command has
been added to allow the invocation of local node services. Syntax has
been added to allow the invocation of static class methods (this is
useful for classes that can't be instantiated, e.g. Class), and the
referencing of static class fields. Syntax has been added to
reference variables which store array values. See
foundry/osl/service/shell/README.shell for details.
- In "fshell", the "createLocation" command has been added to allow
the specification of an ActorManagerName giving the node
where the next actor will be created. The "service" command has been
added as a front end to "service" in shell service. On startup, the
ports provided by the shell service for handling stdout and stderr are
automatically connected to stdout and stderr for the Tcl shell. That
is, stdout and stderr will appear in the "fshell" display.
- Miscellanious: Several random but important changes have
been made. The following is a summary of the changes:
- The BehaviorNotFoundException has been removed from
osl.manager. The original intention was to use this
exception to indicate that a class loader had problems loading an
Actor or ActorImpl instance. However, the event
which triggered such a request has to contain the appropriate
Class objects already. Thus, it is impossible to throw a
BehaviorNotFoundExceptioN since the classes will have already
been successfully loaded.
- Added "null" as a parsable argument to the shell service. During
parsing, the string "null" is converted to the object reference
null.
- The package osl.manager.basic contains standard
implementations of StreamInputActor and
StreamOutputActor. Eventually we'll want to move these
implementations to some standard actor area.
- In osl.manager.ActorManager the signature of the "actor"
methods (i.e. actorCreate, etc) have been changed to be protected and
require an ActorImpl as the first argument. The
ActorImpl class has been changed to include a set of "mgr"
methods which allow access to the protected methods in manager. The
ActorImpl argument required in the "actor" methods are used
to specify the actor implementation that should be affected by the
operation. The change was made to allow non-ActorImpl
threads to call the "actor" operations from within an implementation.
Before, an explicit check was made to ensure that the caller was
really an instance of ActorImpl. However, this makes it
impossible to call a manager function in, for example,
ActorImpl.actorDeliver. This is rather inconvenient and has
been changed in this release. Note that some care must be taken when
using a non-ActorImpl thread to make a manager up-call.
Typically, a foreign thread in an ActorImpl belongs to
another ActorImpl (because of the routing of calls through
managers). Thus, it is important to prevent deadlocks and other
synchronization problems.
- osl.manager.basic.BasicActorManager now supports the
public function actorCreateAlias which may be used by an
ActorImpl to create an ActorName alias for itself.
The implementation currently only works for non-migrating actors.
Haven't figured out yet what to do with the aliases if the aliased
actor migrates. Obviously the aliases could be maintained locally but
this would result in a lot of message forwarding.
- osl.manager.ActorImpl now contains the field
context which is set to the ActorContext that the
local implementation was created with. Certain entries in this field
are copied out when the internal Actor is instantiated. In
other words, if you encapsulate an actor then this field should be
non-null.
- The system logger can now accept requests to log message to the
log associated with a specific thread. This allows log messages to be
routed correctly when the current thread has a different log than the
one where messages should be recorded. Also, three new log files have
been added. The "ActorImplGCs" log records a message each time a
local ActorImpl is GC'd. The "LogGCActivity" records Log
garbage collection cycles. The Log removes logged threads if they
have died (since obviously a dead thread will not be able to write any
more messages). The "Security" log is created if a security manager
is installed, and records security denials.
- In osl.manager.Actor, the destroy may be used
by an actor to commit suicide. The actor is immediately removed from
the system. Note that calling destroy circumvents any normal
garbage collection. Thus dangling references to the actor may be left
behind if it is destroyed. Attempting to utilize these references
will result in runtime exceptions.
Mark Astley
Last modified: Fri Jun 12 17:51:14 CDT 1998