This file is indexed.

/usr/share/mozart/doc/system/node48.html is in mozart-doc 1.4.0-8ubuntu1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

1
2
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>13 Spawning Computations Remotely: Remote</TITLE><LINK href="ozdoc.css" rel="stylesheet" type="text/css"></HEAD><BODY><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node47.html#chapter.connection">&lt;&lt; Prev</A></TD><TD><A href="index.html">- Up -</A></TD><TD><A href="node49.html#chapter.urlurl">Next &gt;&gt;</A></TD></TR></TABLE><DIV id="chapter.remote"><H1><A name="chapter.remote">13 Spawning Computations Remotely: <CODE>Remote</CODE></A></H1><P> The module <CODE>Remote</CODE> provides the class <CODE>Remote<SPAN class="keyword">.</SPAN>manager</CODE> 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: </P><UL><LI><P>A new Oz process with a module manager <CODE><I>M</I></CODE> is created on a networked computer. </P></LI><LI><P>The newly created object <CODE><I>O</I></CODE> serves as a proxy to <CODE><I>M</I></CODE>. <CODE><I>O</I></CODE> is called a <A name="label546"></A><EM>remote module manager</EM>. This allows to start applications remotely that access remote resources by local system modules. </P></LI></UL><P> </P><P> The methods of the class <CODE>Remote<SPAN class="keyword">.</SPAN>manager</CODE> are as follows. </P><P> </P><DL><DT><A name="label547"></A><SPAN class="index"><CODE>init</CODE></SPAN> <A name="label548"></A> </DT><DD><BLOCKQUOTE class="synopsis"><P></P><BLOCKQUOTE class="code"><CODE>init(host:&nbsp;&nbsp;&nbsp;</CODE><CODE>+<I>HostV</I></CODE><CODE>&nbsp;&nbsp;&nbsp;<SPAN class="keyword">&lt;=</SPAN>&nbsp;localhost<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fork:&nbsp;&nbsp;&nbsp;</CODE><CODE>+<I>ForkA</I></CODE><CODE>&nbsp;&nbsp;&nbsp;<SPAN class="keyword">&lt;=</SPAN>&nbsp;automatic<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;detach:&nbsp;</CODE><CODE>+<I>DetachB</I></CODE><CODE>&nbsp;<SPAN class="keyword">&lt;=</SPAN>&nbsp;<SPAN class="keyword">false</SPAN>)</CODE></BLOCKQUOTE><P> </P></BLOCKQUOTE></DD><DD><P>Creates a new Oz process at the computer with host name <CODE><I>HostV</I></CODE> (specified by a virtual string), where <CODE>localhost</CODE> is the computer running the current Oz process. </P><P> <CODE><I>ForkA</I></CODE> (an atom) determines an operating system command to fork the remote Oz process. The atoms <CODE><SPAN class="string">'automatic'</SPAN></CODE> and <CODE><SPAN class="string">'sh'</SPAN></CODE> have special meaning. <CODE><SPAN class="string">'automatic'</SPAN></CODE> is the default method. Other useful values for <CODE><I>ForkA</I></CODE> are <CODE><SPAN class="string">'rsh'</SPAN></CODE> (remote shell command) and <CODE><SPAN class="string">'ssh'</SPAN></CODE> (secure shell command). </P><DIV class="apropos"><P class="margin"><CODE>sh</CODE> configuration</P><P> If <CODE><SPAN class="string">'sh'</SPAN></CODE> is used as fork method, a new Oz engine is created on the current host by using the Unix <CODE>sh</CODE> command. You can test whether this method works on your computer by: </P><BLOCKQUOTE class="code"><CODE>sh&nbsp;-c&nbsp;<SPAN class="string">'ozengine&nbsp;x-oz://system/RemoteServer.ozf&nbsp;--test'</SPAN></CODE></BLOCKQUOTE><P> This should be always the case, if Mozart has been installed properly on your computer. This in particular requires that <CODE>$<SPAN class="variablename">OZHOME</SPAN>/bin</CODE> is in your path of executables (<CODE>$<SPAN class="variablename">OZHOME</SPAN></CODE> refers to the directory where Mozart has been installed). </P></DIV><P> Note that the value of <CODE><I>HostV</I></CODE> is ignored (the hostname is assumed to be <CODE>localhost</CODE>), if <CODE><SPAN class="string">'sh'</SPAN></CODE> is used as fork method. </P><P> If <CODE><I>HostV</I></CODE> is <CODE><SPAN class="string">'localhost'</SPAN></CODE> and <CODE><I>ForkA</I></CODE> is <CODE><SPAN class="string">'automatic'</SPAN></CODE> (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 <CODE><SPAN class="string">'distribution.virtualsites'</SPAN></CODE> carries a boolean telling whether this facility, called <A name="label549"></A><EM>virtual sites</EM>, is supported in the running Mozart process; the <CODE><SPAN class="string">'sh'</SPAN></CODE> fork method is used as a fall-back. </P><P> If <CODE><I>HostV</I></CODE> is different from <CODE><SPAN class="string">'localhost'</SPAN></CODE> and the method is <CODE><SPAN class="string">'automatic'</SPAN></CODE> the command <CODE><SPAN class="string">'rsh'</SPAN></CODE> is used. <CODE><SPAN class="string">'rsh'</SPAN></CODE> creates a shell remotely by using the Unix <CODE>rsh</CODE> command, which in turn creates the new Oz engine. </P><DIV class="apropos"><P class="margin"><CODE>rsh</CODE> configuration</P><P> Remote managers with method <CODE>rsh</CODE> only work properly, if the <CODE>rsh</CODE> command has been set up properly. You can test it for the host <I>Host</I> by executing the following command in the operating system shell: </P><BLOCKQUOTE class="code"><CODE>rsh&nbsp;</CODE><I>Host</I><CODE>&nbsp;ozengine&nbsp;x-oz://system/RemoteServer.ozf&nbsp;--test</CODE></BLOCKQUOTE><P> If the message </P><BLOCKQUOTE class="code"><CODE>Remote:&nbsp;Test&nbsp;succeeded...</CODE></BLOCKQUOTE><P> is printed, your configuration is okay. This requires two things: </P><OL type="1"><LI><P>Execution of <CODE>rsh&nbsp;</CODE><I>Host</I> must not prompt for a password. This is usually achieved by having a special file <CODE>.rhosts</CODE> in your home directory. Each entry in that file must be a host name. For those hosts having an entry in that file, <CODE>rsh</CODE> does not prompt for a password. </P><P> Take the following sample <CODE>.rhosts</CODE> file at the computer <CODE>wallaby.ps.uni-sb.de</CODE>: </P><BLOCKQUOTE class="code"><CODE>godzilla.ps.uni-sb.de<BR>bamse.sics.se</CODE></BLOCKQUOTE><P> If <CODE>rsh&nbsp;wallaby.ps.uni-sb.de</CODE> is executed on <CODE>bamse.sics.se</CODE> or <CODE>godzilla.ps.uni-sb.de</CODE>, then <CODE>rsh</CODE> does not prompt for a password. </P><P> With other words, all host names that you ever want to use with <CODE>Remote.manager</CODE> should be in <CODE>.rhosts</CODE>. </P></LI><LI><P>After the login performed by <CODE>rsh</CODE> the command <CODE>ozengine</CODE> must be executable. This should be always the case, if Mozart has been installed properly on your computer. This in particular requires that <CODE>$<SPAN class="variablename">OZHOME</SPAN>/bin</CODE> is in your path of executables (<CODE>$<SPAN class="variablename">OZHOME</SPAN></CODE> refers to the directory where Mozart has been installed). </P></LI></OL><P> </P></DIV><DIV class="apropos"><P class="margin">Other commands</P><P> Rather than using <CODE>rsh</CODE>, any value for <CODE><I>ForkA</I></CODE> is possible. In that case the following operating system command: </P><BLOCKQUOTE class="code"><I>ForkA</I><CODE>&nbsp;</CODE><I>Host</I><CODE>&nbsp;ozengine&nbsp;x-oz://system/RemoteServer.ozf&nbsp;--test</CODE></BLOCKQUOTE><P> should print the message </P><BLOCKQUOTE class="code"><CODE>Remote:&nbsp;Test&nbsp;succeeded...</CODE></BLOCKQUOTE><P> </P></DIV><P> A prominent example of a different command and a very recommended substitute for <CODE>rsh</CODE> is <CODE>ssh</CODE> (secure shell) which is a more powerful and secure replacement for <CODE>rsh</CODE>. For more information on <CODE>ssh</CODE>, see <A href="http://www.ssh.fi"><CODE>www.ssh.fi</CODE></A>. </P><P> If <CODE><I>DetachB</I></CODE> is <CODE><SPAN class="keyword">false</SPAN></CODE>, 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, <CODE><I>DetachB</I></CODE> is <CODE><SPAN class="keyword">true</SPAN></CODE>) is independent of the creating process. </P><DIV class="danger"><P class="margin"><IMG align="top" alt="Danger" src="danger.gif"></P><P> On some platforms (in particular on <CODE>solaris<SPAN class="keyword">-</SPAN>sparc</CODE>) 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. </P></DIV><DIV class="danger"><P class="margin"><IMG align="top" alt="Danger" src="danger.gif"></P><P> 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 <CODE>ipcs</CODE> and <CODE>ipcrm</CODE>) to get rid of them. </P></DIV></DD><DT><A name="label550"></A><SPAN class="index"><CODE>link</CODE></SPAN> <A name="label551"></A> </DT><DD><BLOCKQUOTE class="synopsis"><P></P><BLOCKQUOTE class="code"><CODE>link(url:</CODE><CODE>+<I>UrlV</I></CODE><CODE>&nbsp;</CODE><CODE><I>ModuleR</I></CODE><CODE>&nbsp;<SPAN class="keyword">&lt;=</SPAN>&nbsp;_)</CODE></BLOCKQUOTE><P> </P><BLOCKQUOTE class="code"><CODE>link(name:</CODE><CODE>+<I>NameV</I></CODE><CODE>&nbsp;</CODE><CODE><I>ModuleR</I></CODE><CODE>&nbsp;<SPAN class="keyword">&lt;=</SPAN>&nbsp;_)</CODE></BLOCKQUOTE><P> </P></BLOCKQUOTE></DD><DD><P>Links the module identified either by a url <CODE><I>UrlV</I></CODE> (a virtual string) or a module name <CODE><I>NameV</I></CODE> (a virtual string). Returns a module <CODE><I>ModuleR</I></CODE>. </P><P> For explanation see <A href="node7.html#chapter.module">Chapter&nbsp;2</A>. </P></DD><DT><A name="label552"></A><SPAN class="index"><CODE>apply</CODE></SPAN> <A name="label553"></A> </DT><DD><BLOCKQUOTE class="synopsis"><P></P><BLOCKQUOTE class="code"><CODE>apply(</CODE><CODE>+<I>Functor</I></CODE><CODE>&nbsp;</CODE><CODE><I>ModuleR</I></CODE><CODE>&nbsp;<SPAN class="keyword">&lt;=</SPAN>&nbsp;_)</CODE></BLOCKQUOTE><P> </P><BLOCKQUOTE class="code"><CODE>apply(url:</CODE><CODE>+<I>UrlV</I></CODE><CODE>&nbsp;</CODE><CODE>+<I>Functor</I></CODE><CODE>&nbsp;</CODE><CODE><I>ModuleR</I></CODE><CODE>&nbsp;<SPAN class="keyword">&lt;=</SPAN>&nbsp;_)</CODE></BLOCKQUOTE><P> </P><BLOCKQUOTE class="code"><CODE>apply(name:</CODE><CODE>+<I>NameV</I></CODE><CODE>&nbsp;</CODE><CODE>+<I>Functor</I></CODE><CODE>&nbsp;</CODE><CODE><I>ModuleR</I></CODE><CODE>&nbsp;<SPAN class="keyword">&lt;=</SPAN>&nbsp;_)</CODE></BLOCKQUOTE><P> </P></BLOCKQUOTE></DD><DD><P>Applies the functor <CODE><I>Functor</I></CODE>, where the url <CODE><I>UrlV</I></CODE> (a virtual string) or the module name <CODE><I>NameV</I></CODE> (a virtual string) serve as base url for resolving the functor's import. </P><P> For explanation see <A href="node7.html#chapter.module">Chapter&nbsp;2</A>. </P></DD><DT><A name="label554"></A><SPAN class="index"><CODE>enter</CODE></SPAN> <A name="label555"></A> </DT><DD><BLOCKQUOTE class="synopsis"><P></P><BLOCKQUOTE class="code"><CODE>enter(url:</CODE><CODE>+<I>UrlV</I></CODE><CODE>&nbsp;</CODE><CODE><I>ModuleR</I></CODE><CODE>)</CODE></BLOCKQUOTE><P> </P><BLOCKQUOTE class="code"><CODE>enter(name:</CODE><CODE>+<I>NameV</I></CODE><CODE>&nbsp;</CODE><CODE><I>ModuleR</I></CODE><CODE>)</CODE></BLOCKQUOTE><P> </P></BLOCKQUOTE></DD><DD><P>Installs the module <CODE><I>ModuleR</I></CODE> under the url <CODE><I>UrlV</I></CODE> (a virtual string) or the module name <CODE><I>NameV</I></CODE> (a virtual string). </P><P> For explanation see <A href="node7.html#chapter.module">Chapter&nbsp;2</A>. </P></DD><DT><A name="label556"></A><SPAN class="index"><CODE>ping</CODE></SPAN> <A name="label557"></A> </DT><DD><BLOCKQUOTE class="synopsis"><P></P><BLOCKQUOTE class="code"><CODE>ping()</CODE></BLOCKQUOTE><P> </P></BLOCKQUOTE></DD><DD><P>Raises exception if remote process is dead. Blocks until executed by remote process. </P></DD><DT><A name="label558"></A><SPAN class="index"><CODE>close</CODE></SPAN> <A name="label559"></A> </DT><DD><BLOCKQUOTE class="synopsis"><P></P><BLOCKQUOTE class="code"><CODE>close()</CODE></BLOCKQUOTE><P> </P></BLOCKQUOTE></DD><DD><P>Performs a controlled shutdown of all remote processes (for a discussion of controlled shutdown see <A href="../dstutorial/node2.html#section.distmodel.shutdown">Section&nbsp;2.2.1 of ``Distributed Programming in Mozart - A Tutorial Introduction''</A>). </P></DD></DL><P> </P><H2><A name="label560">13.1 Process Termination and Remote Managers</A></H2><P>Here are some tentative explanations of what happens to the children of a process when the latter is terminated. </P><UL><LI><P>if a process is properly shutdown, then detached children survive and non-detached children are terminated.</P></LI><LI><P>if a process is killed with <CODE>kill&nbsp;-INT</CODE>, then its children are terminated whether they are detached or not.</P></LI><LI><P>if a process is killed with <CODE>kill&nbsp;-KILL</CODE>, then no child is terminated because the proper shutdown sequence is not executed.</P></LI><LI><P>if a process is killed by typing <SPAN class="key">C-c</SPAN>, then the <CODE>INT</CODE> signal is sent to the <EM>process group</EM> to which both parent and children belong.<A href="node48.html#label561"><SUP>1</SUP></A> Thus all are terminated.</P></LI></UL><P> </P></DIV><TABLE align="center" border="0" cellpadding="6" cellspacing="6" class="nav"><TR bgcolor="#DDDDDD"><TD><A href="node47.html#chapter.connection">&lt;&lt; Prev</A></TD><TD><A href="index.html">- Up -</A></TD><TD><A href="node49.html#chapter.urlurl">Next &gt;&gt;</A></TD></TR></TABLE><HR align="left" width="30%"><DIV class="footnote"><A name="label561">1. </A>This is the case in the current regime, but could be changed if desired</DIV><HR><ADDRESS><A href="http://www.ps.uni-sb.de/~duchier/">Denys&nbsp;Duchier</A>, <A href="http://www.ps.uni-sb.de/~kornstae/">Leif&nbsp;Kornstaedt</A>, <A href="http://www.ps.uni-sb.de/~homik/">Martin&nbsp;Homik</A>, <A href="http://www.ps.uni-sb.de/~tmueller/">Tobias&nbsp;Müller</A>, <A href="http://www.ps.uni-sb.de/~schulte/">Christian&nbsp;Schulte</A> and&nbsp;<A href="http://www.info.ucl.ac.be/~pvr">Peter&nbsp;Van Roy</A><BR><SPAN class="version">Version 1.4.0 (20110908185330)</SPAN></ADDRESS></BODY></HTML>