13 Spawning Computations Remotely: Remote

The module Remote provides the class Remote.manager by which new Oz processes on arbitrary networked computers that also have Mozart installed can be created. Creating an instance of that class does the following two things:

• A new Oz process with a module manager M is created on a networked computer.

• The newly created object O serves as a proxy to M. O is called a remote module manager. This allows to start applications remotely that access remote resources by local system modules.

The methods of the class Remote.manager are as follows.

init

init(host:   +HostV   <= localhost
     fork:   +ForkA   <= automatic
     detach: +DetachB <= false)

Creates a new Oz process at the computer with host name HostV (specified by a virtual string), where localhost is the computer running the current Oz process.

ForkA (an atom) determines an operating system command to fork the remote Oz process. The atoms 'automatic' and 'sh' have special meaning. 'automatic' is the default method. Other useful values for ForkA are 'rsh' (remote shell command) and 'ssh' (secure shell command).

sh configuration

If 'sh' is used as fork method, a new Oz engine is created on the current host by using the Unix sh command. You can test whether this method works on your computer by:

sh -c 'ozengine x-oz://system/RemoteServer.ozf --test'

This should be always the case, if Mozart has been installed properly on your computer. This in particular requires that $OZHOME/bin is in your path of executables ($OZHOME refers to the directory where Mozart has been installed).

Note that the value of HostV is ignored (the hostname is assumed to be localhost), if 'sh' is used as fork method.

If HostV is 'localhost' and ForkA is 'automatic' (which is the default), then on some platforms the forked and forking processes communicate through shared memory rather than sockets, which is more efficient. The system property 'distribution.virtualsites' carries a boolean telling whether this facility, called virtual sites, is supported in the running Mozart process; the 'sh' fork method is used as a fall-back.

If HostV is different from 'localhost' and the method is 'automatic' the command 'rsh' is used. 'rsh' creates a shell remotely by using the Unix rsh command, which in turn creates the new Oz engine.

rsh configuration

Remote managers with method rsh only work properly, if the rsh command has been set up properly. You can test it for the host Host by executing the following command in the operating system shell:

rsh Host ozengine x-oz://system/RemoteServer.ozf --test

If the message

Remote: Test succeeded...

is printed, your configuration is okay. This requires two things:

1. Execution of rsh Host must not prompt for a password. This is usually achieved by having a special file .rhosts in your home directory. Each entry in that file must be a host name. For those hosts having an entry in that file, rsh does not prompt for a password.

   Take the following sample .rhosts file at the computer wallaby.ps.uni-sb.de:

   godzilla.ps.uni-sb.de
bamse.sics.se

   If rsh wallaby.ps.uni-sb.de is executed on bamse.sics.se or godzilla.ps.uni-sb.de, then rsh does not prompt for a password.

   With other words, all host names that you ever want to use with Remote.manager should be in .rhosts.

2. After the login performed by rsh the command ozengine must be executable. This should be always the case, if Mozart has been installed properly on your computer. This in particular requires that $OZHOME/bin is in your path of executables ($OZHOME refers to the directory where Mozart has been installed).

Other commands

Rather than using rsh, any value for ForkA is possible. In that case the following operating system command:

ForkA Host ozengine x-oz://system/RemoteServer.ozf --test

should print the message

Remote: Test succeeded...

A prominent example of a different command and a very recommended substitute for rsh is ssh (secure shell) which is a more powerful and secure replacement for rsh. For more information on ssh, see www.ssh.fi.

If DetachB is false, a non-detached process is created. A non-detached process terminates as soon as the creating process does (think of crashes, there will be no orphaned processes). The lifetime of a detached process (that is, DetachB is true) is independent of the creating process.

On some platforms (in particular on solaris-sparc) the operating system in its default configuration does not support virtual sites efficiently. Namely, the Solaris OS limits the total number of shared memory pages per process to six and the number of shared memory pages system-wide to 100, while each connected Mozart process requires at least two shared memory pages for efficient communication. Please ask your system administrator to increase those limits with respect to your needs.

The Mozart system tries to do its best to reclaim shared memory identifiers, even upon process crashes, but it is still possible that some shared memory pages become unaccounted and thus stay forever in the OS. In these cases please use Unix utilities (on Solaris and Linux these are ipcs and ipcrm) to get rid of them.

link

link(url:+UrlV ModuleR <= _)

link(name:+NameV ModuleR <= _)

Links the module identified either by a url UrlV (a virtual string) or a module name NameV (a virtual string). Returns a module ModuleR.

For explanation see Chapter 2.

apply

apply(+Functor ModuleR <= _)

apply(url:+UrlV +Functor ModuleR <= _)

apply(name:+NameV +Functor ModuleR <= _)

Applies the functor Functor, where the url UrlV (a virtual string) or the module name NameV (a virtual string) serve as base url for resolving the functor's import.

For explanation see Chapter 2.

enter

enter(url:+UrlV ModuleR)

enter(name:+NameV ModuleR)

Installs the module ModuleR under the url UrlV (a virtual string) or the module name NameV (a virtual string).

For explanation see Chapter 2.

ping

ping()

Raises exception if remote process is dead. Blocks until executed by remote process.

close

close()

Performs a controlled shutdown of all remote processes (for a discussion of controlled shutdown see Section 2.2.1 of ``Distributed Programming in Mozart - A Tutorial Introduction'').

13.1 Process Termination and Remote Managers

Here are some tentative explanations of what happens to the children of a process when the latter is terminated.

• if a process is properly shutdown, then detached children survive and non-detached children are terminated.

• if a process is killed with kill -INT, then its children are terminated whether they are detached or not.

• if a process is killed with kill -KILL, then no child is terminated because the proper shutdown sequence is not executed.

• if a process is killed by typing C-c, then the INT signal is sent to the process group to which both parent and children belong.¹ Thus all are terminated.