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.