22 Interprocess communication toolbox
"Scilab description"
22.1 AdCommunications advanced communication toolbox for parallel programming
DESCRIPTION :
This the beta version of the Advanced Communications Toolbox (ACT).
This toolbox is based on existing libraries, such as
PVM - Parallel Vitual Machine
PBLAS - Message Passing Library dedicated to Matrix
ScaLapack - Parallel linear algebra Library
ACT manage remote executions of softwares and allow efficient
exchanges of messages between those softwares. It offers the
possibility to exploit numerous machines on a network, as a virtual
computer, by creating a distributed group of independent softwares.
See Also :
Example X
22.2 Example just to test the environment
DESCRIPTION :
We are the knights who say ni!
22.3 pvm communications with other applications using Parallel Virutal Machine
DESCRIPTION :
PVM
is a software system that enables a collection of heterogeneous
computers to be used as a coherent and flexible concurrent computational
resource.
The individual computers may be shared- or local-memory multiprocessors,
vector supercomputers, specialized graphics engines, or scalar
workstations, that may be interconnected by a variety of networks,
such as ethernet, FDDI.
Daemon programs (pvmd3) provide communication and process control
between computers (see PVM manpage and manual for more details).
Most important functions of the PVM communication library are included in Scilab.
WARNING :
PVM must be installed in your envriromnent before using it in Scilab. PVM
scilab have been developped using the version 3.3.7 of the PVM library.
AUTHORS :
PVM have been developped by A. L. Beguelin, J. J. Dongarra, G. A. Geist, W. C. Jiang, R. J. Manchek, B. K. Moore, V. S. Sunderam (see http://www.netlib.org/pvm3)
See Also :
pvm_barrier X, pvm_mytid X, pvm_bcast X, pvm_parent X, pvm_config X, pvm_delhosts X, pvm_recv X, pvm_exit X, pvm_send X, pvm_getinst X, pvm_spawn X, pvm_gettid X, pvm_spawn_independent X, pvm_gsize X, pvm_tasks X, pvm_joingroup X, pvm_tidtohost X
pvm_kill, pvm_lvgroup, pvm_start, pvm_halt
22.4 pvm_addhosts add hosts to the virtual machine.
CALLING SEQUENCE :
[infos] = pvm_addhosts(hosts)
PARAMETERS :
- hosts
: row of strings, naming the hosts to be added.
- infos
: row of integer, corresponding to the status for each host.
DESCRIPTION :
pvm_addhosts adds the computers named in
hosts
to the configuration of computers making up the virtual machine.
The names should have the same syntax as lines of a pvmd hostfile
(see man page for pvmd3):
A hostname followed by options of the form xx=y.
The array
infos
can be checked to determine the status for each host.
Values less than zero indicate an error,
while positive values are TIDs of the new hosts.
The status of hosts can be requested by the application using
pvm_config.
If a host fails it will be automatically deleted from the configuration.
Using pvm_addhosts a replacement host can be added by the application,
however
it is the responsibility of the
application developer to make his application tolerant of host failure.
Another use of this feature would be to add more hosts
as they become available, for example on a weekend, or if the
application dynamically determines it could use more computational power.
EXAMPLE :
info = pvm_addhosts(["isostar","loop"])
See Also :
pvm_delhosts X, pvm_config X
22.5 pvm_barrier blocks the calling process until all processes
in a group have called it.
CALLING SEQUENCE :
[info] = pvm_barrier(group,count)
PARAMETERS :
- type
: string, name of an existing group.
- count
: integer, specifying the number of group members that must call
pvm_barrier before they are all released.
- info
: integer, status code returned by the routine.
DESCRIPTION :
pvm_barrier blocks the calling process until
count
members of the
group
have called pvm_barrier.
The count argument is required because processes could be
joining the given group after other processes have called
pvm_barrier. Thus PVM doesn't know how many group members
to wait for at any given instant. Although count can be set less,
it is typically the total number of members of the group.
So the logical function of the pvm_barrier call
is to provide a group synchronization.
During any given barrier call all participating group members
must call barrier with the same count value.
Once a given barrier has been successfully passed,
pvm_barrier can be called again by the same group using the same
group name.
If pvm_barrier is successful,
info
will be 0. If some error occurs then
info
will be < 0.
EXAMPLE :
info = pvm_barrier( "worker", pvm_gsize("worker") )
See Also :
pvm_joingroup X
22.6 pvm_bcast broacasts a message to all members of a group
CALLING SEQUENCE :
[info] = pvm_bcast(group, buff, msgtag)
PARAMETERS :
- group
: string, string group name of an existing group.
- buff
: data to be send.
- msgtag
: integer, message tag supplied by the user.
- info
: integer,
DESCRIPTION :
pvm_bcast broadcasts a message to all the members of
group.
In PVM 3.2 and later the broadcast message is not sent back to the sender.
Any PVM task can call pvm_bcast(), it need not be a member of the group.
The content of the message can be distinguished by
msgtag.
If pvm_bcast is successful,
info
will be 0. If some error occurs then
info
will be < 0.
pvm_bcast is asynchronous.
Computation on the sending processor resumes as soon as the message is
safely on its way to the receiving processors. This is in
contrast to synchronous communication, during which computation on
the sending processor halts until a matching receive is
executed by all the receiving processors.
pvm_bcast first determines the tids of the
group members by checking a group data base.
A multicast is performed to these tids.
If the group is changed during a broadcast the change will not
be reflected in the broadcast.
Multicasting is not supported by most multiprocessor vendors.
Typically their native calls only support broadcasting to all the user's processes on a multiprocessor. Because of this omission,
pvm_bcast may not be an efficient communication method on
some multiprocessors.
EXAMPLE :
info = pvm_bcast( "worker",[12+%i,4,5;3,4+%i,5],10)
See Also :
pvm_joingroup X
22.7 pvm_config sends a message
CALLING SEQUENCE :
res = pvm_config()
PARAMETERS :
- res, list of 7 elements such that:
- res(1):
integer returning the number of hosts (pvmds) in the virtual machine.
- res(2):
integer returning the number of different data formats being used.
- res(3):
integer returning pvmd task ID for host.
- res(4):
character string returning name of host.
- res(5):
character string returning architecture name of host
- res(6):
integer returning relative speed of host. Default value is 1000.
- res(7):
integer status code returned by the routine.
DESCRIPTION :
pvm_config returns information about
the present virtual machine. The information returned is
similar to that available from the console command
conf.
The pvm_config function returns information about the entire
virtual machine in one call.
If pvm_config is successful,
info
will be 0.
If some error occurs then
info
will be < 0.
EXAMPLE :
res = pvm_config()
See Also :
pvm_tasks X
22.8 pvm_delhosts deletes hosts from the virtual machine.
CALLING SEQUENCE :
infos = pvm_delhosts(hosts)
PARAMETERS :
- hosts
: row of strings, containing the names of the machines to be deleted.
- infos
: row of integers, contains the
status code returned by the routine for the individual hosts.
DESCRIPTION :
pvm_delhosts deletes the computers of
hosts
from the existing configuration of computers making up the virtual
machine.
All PVM processes and the pvmd running on these computers are
killed as the computer is deleted.
The array
infos
can be checked to determine the status of each host.
Values less than zero indicate an error,
while zero values indicate a success.
If a host fails, the PVM system will continue to function and will
automatically delete this host from the virtual machine.
It is the responsibility of the
application developer to make his application tolerant of host failure.
EXAMPLE :
info = pvm_delhosts(["isostar","loop"])
See Also :
pvm_addhosts X
22.9 pvm_exit tells the local pvmd that this process is leaving PVM.
CALLING SEQUENCE :
[info] = pvm_exit()
PARAMETERS :
DESCRIPTION :
pvm_exit tells the local pvmd
that this process is leaving PVM.
This routine does not kill the process, which can continue to
perform tasks just like any other serial process.
pvm_exit should be called by all PVM processes before
they stop or exit for good. It must be called
by processes that were not started with pvm_spawn.
EXAMPLE :
pvm_exit()
See Also :
pvm X
22.10 pvm_get_timer Gets the system's notion of the current time.
CALLING SEQUENCE :
[time] = pvm_get_timer()
PARAMETERS :
DESCRIPTION :
pvm_get_timer returns the time elapsed since the last call of
pvm_get_timer or the last call of pvm_set_timer. The time is
expressed in elapsed microseconds. The resolution of the system clock
is hardware dependent; the time may be updated continuously or in
clock ticks.
timer
will be > 0.
If some error occurs then
timer
will be -1.
EXAMPLE :
B = rand(100,100);
A = rand(100,100);
pvm_set_timer();C=A*B;t=pvm_get_timer()
See Also :
pvm_set_timer X
22.11 pvm_getinst returns the instance number in a group of a PVM process.
CALLING SEQUENCE :
[inum] = pvm_getinst(group, tid)
PARAMETERS :
- group
: string, string group name of an existing group.
- tid
: integer, task identifier of a PVM process.
- inum
: integer, instance number returned by the routine.
DESCRIPTION :
pvm_getinst takes a group name
group
and a PVM task identifier
tid
and returns the unique
instance number that corresponds to the input.
It can be called by any task whether in the group or not.
If pvm_getinst is successful,
inum
will be >= 0.
If some error occurs then
inum
will be < 0.
EXAMPLE :
inum = pvm_getinst( "worker", pvm_mytid() )
See Also :
pvm_joingroup X, pvm_gettid X
22.12 pvm_gettid returns the tid of the process identified by a
group name and instance number.
CALLING SEQUENCE :
[tid] = pvm_gettid(group, inum)
PARAMETERS :
- group
: string, string that contains the name of an existing group.
- inum
: string, instance number of the process in the group.
- tid
: integer
DESCRIPTION :
pvm_gettid returns the tid of the PVM process
identified by the group name
group
and the instance number
inum.
If pvm_gettid is successful,
tid
will be > 0.
If some error occurs then
tid
will be < 0.
EXAMPLE :
tid = pvm_gettid("worker",0)
See Also :
pvm_joingroup X, pvm_getinst X
22.13 pvm_gsize returns the number of members presently in the named group.
CALLING SEQUENCE :
[nb] = pvm_gsize(group)
PARAMETERS :
- group
: string, string group name of an existing group.
- nb
: integer, returning the number of members presently in the group.
DESCRIPTION :
pvm_gsize returns the size of
the group named
group.
If there is an error
nb
will be negative.
Since groups can change dynamically in PVM 3.0,
this routine can only guarantee to return the instantaneous
size of a given group.
EXAMPLE :
nb_worker = pvm_gsize( "worker" )
See Also :
pvm_joingroup X
22.14 pvm_halt stops the PVM daemon
CALLING SEQUENCE :
[info] = pvm_halt()
PARAMETERS :
- info
: integer, status code returned by the routine.
Values less than zero indicate an error.
DESCRIPTION :
pvm_halt kills all PVM tasks, all the remote daemons, and the
local daemon. If the master pvmd is killed manually it should be
sent a SIGTERM signal to allow it to kill the remote pvmds and clean
up various files.
The pvmd can be killed in a manner that leaves the file /tmp/pvmd.uid
behind on one or more hosts. Uid is the numeric user ID (from
/etc/passwd) of the user. This will prevent PVM from restarting on
that host. Deletion of this file will fix this problem:
rm `( grep $user /etc/passwd || ypmatch $user passwd )
| awk -F: '{print "/tmp/pvmd."$3; exit}'`
For example:
-->pvm_halt()
ans =
0.
-->pvm_halt()
ans =
- 14.
Error -14 means: pvm_halt(): Can't contact local daemon
See Also :
pvm_start X, pvm_addhosts X, pvm_config X
22.15 pvm_joingroup enrolls the calling process in a named group.
CALLING SEQUENCE :
[inum] = pvm_joingroup(group)
PARAMETERS :
- group
: string, string group name of an existing group.
- inum
: integer, instance number returned by the routine.
DESCRIPTION :
pvm_joingroup enrolls the calling task in
the group named
group
and returns the instance number
inum
of this task in this group.
If there is an error
inum
will be negative.
Instance numbers start at 0 and count up.
When using groups a (group, inum) pair uniquely identifies a
PVM process.
This is consistent with the PVM 2.4 naming schemes.
If a task leaves a group by calling pvm_lvgroup
and later rejoins the same group,
the task is not guaranteed to get the same instance number.
PVM attempts to reuse old instance numbers, so when a task
joins a group it will get the lowest available instance number.
A task can be a member of multiple groups simultaneously.
EXAMPLE :
inum = pvm_joingroup( "worker" )
See Also :
pvm_lvgroup X
22.16 pvm_kill Terminates a specified PVM process.
CALLING SEQUENCE :
[infos] = pvm_kill(tids)
PARAMETERS :
- tids
: row of integer, task identifier of the PVM process to be killed
(not yourself).
- infos
: row of integer, status code returned by the routine.
Values less than zero indicate an error.
DESCRIPTION :
pvm_kill sends a terminate (SIGTERM) signal
to the PVM process identified by
tids.
In the case of multiprocessors the terminate signal is replaced
with a host dependent method for killing a process.
If pvm_kill is successful,
The array
infos
can be checked to determine the status for each process.
Values less than zero indicate an error,
while zero values indicate a success.
pvm_kill is not designed to kill the calling process.
To kill yourself in C call pvm_exit() followed by quit().
EXAMPLE :
info = pvm_kill(262153)
See Also :
pvm_exit X
22.17 pvm_lvgroup Unenrolls the calling process from a named group.
CALLING SEQUENCE :
[info] = pvm_lvgroup(group)
PARAMETERS :
- group
: string, group name of an existing group.
- info
: integer, status code returned by the routine.
DESCRIPTION :
pvm_lvgroup unenrolls the calling process from
the group named
group.
If there is an error
info
will be negative.
If a process leaves a group by calling either pvm_lvgroup
or pvm_exit, and later rejoins the same group, the process
may be assigned a new instance number. Old instance
numbers are reassigned to processes calling pvm_joingroup.
EXAMPLE :
info = pvm_lvgroup( "worker" )
See Also :
pvm_joingroup X
22.18 pvm_mytid returns the tid of the calling process.
CALLING SEQUENCE :
[tid] = pvm_mytid()
PARAMETERS :
- tid
: integer, the task identifier of the calling PVM process.
Values less than zero indicate an error.
DESCRIPTION :
pvm_mytid enrolls this process
into PVM on its first call. It also generates a unique
tid
if this process was not created by pvm_spawn.
pvm_mytid returns the
tid
of the calling process
and can be called multiple times in an application.
Any PVM system call (not just pvm_mytid) will enroll a task in PVM
if the task is not enrolled before the call.
The tid is a 32 bit positive integer created by the local pvmd.
The 32 bits are divided into fields that encode various
information about this process such as its location in
the virtual machine (i.e. local pvmd address),
the CPU number in the case where the process is on
a multiprocessor, and a process ID field. This information
is used by PVM and is not expected to be used by applications.
Applications should not attempt to predict or interpret the tid with
the exception of calling tidtohost()
If PVM has not been started before an application calls pvm_mytid
the returned
tid
will be < 0.
EXAMPLE :
tid = pvm_mytid()
See Also :
pvm_tidtohost X, pvm_parent X
22.19 pvm_parent returns the tid of the process that spawned
the calling process.
CALLING SEQUENCE :
tid = pvm_parrent()
PARAMETERS :
- tid
: integer, the task identifier of the parent of the calling
process.
DESCRIPTION :
pvm_parent returns the
tid
of the process
that spawned the calling process.
If the calling process was
not created with pvm_spawn, then
tid
is set to
PvmNoParent=-23
EXAMPLE :
tid = pvm_parent()
See Also :
pvm_spawn X
22.20 pvm_recv receive a message.
CALLING SEQUENCE :
[buff, info] = pvm_recv(tid, msgtag)
PARAMETERS :
- tid
: integer, task identifier of sending process supplied by the user.
- msgtag : integer, message tag supplied by the user. msgtag should be
>= 0.
- buff
: scilab variable, where the received message will be stored.
- info
: integer, status code returned by the routine. Values less than zero indicate an error.
DESCRIPTION :
pvm_recv blocks the process until a message with label
msgtag
has arrived from
tid.
pvm_recv then places the message in buff.
A -1 in
msgtag
or
tid
matches anything. This allows the user the following options. If tid
= -1 and msgtag is defined by the user, then pvm_recv will accept a
message from any process which has a matching msgtag. If msgtag = -1
and tid is defined by the user, then pvm_recv will accept any message
that is sent from process tid. If tid = -1 and msgtag = -1, then
pvm_recv will accept any message from any process.
The PVM model guarantees the following about message order. If task 1
sends message A to task 2, then task 1 sends message B to task 2,
message A will arrive at task 2 before message B. Moreover, if both
messages arrive before task 2 does a receive, then a wildcard receive
will always return message A.
info
will be the status code returned by the routine.
If some error occurs then
info
will be < 0.
pvm_recv is blocking which means the routine waits until a message
matching the user specified tid and msgtag values arrives at the local
pvmd. If the message has already arrived then pvm_recv returns
immediately with the message.
Once pvm_recv returns, the data in the message can be unpacked
into the user's memory using the unpack routines.
EXAMPLE :
[b,info] = pvm_recv(pvm_parent(),100)
g = pvm_recv(pvm_parent(),200)
See Also :
pvm_send X, pvm_bcast X
22.21 pvm_send immediately sends (or multicast) data.
CALLING SEQUENCE :
[info] = pvm_send(tids,buff,msgtag)
PARAMETERS :
- tids
: row of integers, contains the task IDs of the tasks to be sent to.
- buff
: scilab variable.
- msgtag : integer, message tag supplied by the user. msgtag should be
>= 0. It allows the user's program to distinguish between different
kinds of messages .
- info
: integer, status code returned by the routine.
Values less than zero indicate an error.
DESCRIPTION :
pvm_send sends (or multicasts) a message
to the PVM process identified in the
tids
array. Note that the message is not sent to the caller even if listed
in the array of tids.
msgtag
is used to label the content of the message.
If pvm_send is successful,
info
will be 0. If some error occurs then
info
will be < 0.
The pvm_send routine is asynchronous. Computation on the sending
processor resumes as soon as the message is safely on its way to the
receiving processor. This is in contrast to synchronous
communication, during which computation on the sending processor halts
until the matching receive is executed by the receiving processor.
If a multicast is performed, pvm_send first determines which other
pvmds contain the specified tasks. Then passes the message to these
pvmds which in turn distribute the message to their local tasks
without further network traffic.
The PVM model guarantees the following about message order. If task 1
sends message A to task 2, then task 1 sends message B to task 2,
message A will arrive at task 2 before message B. Moreover, if both
messages arrive before task 2 does a receive, then a wildcard receive
will always return message A.
Terminating a PVM task immediately after sending a message or messages
from it may result in those messages being lost. To be sure, always
call pvm_exit() before stopping.
EXAMPLE :
A = rand(5,5)*(1+%i);
deff('[x]=f(y)','x = 1/y')
info = pvm_send([262150, 262152], A(1:2:5,:), 100)
pvm_send(262146,f,200)
See Also :
pvm_recv X, pvm_bcast X
22.22 pvm_set_timer Sets the system's notion of the current time.
CALLING SEQUENCE :
[info] = pvm_set_timer()
PARAMETERS :
DESCRIPTION :
pvm_set_timer initialized the timer.
info
will be 0.
If some error occurs then
info
will be -1.
EXAMPLE :
pvm_set_timer()
See Also :
pvm_get_timer X
22.23 pvm_spawn Starts new Scilab processes.
CALLING SEQUENCE :
[tids, numt] = pvm_spawn(task, ntask, [where])
PARAMETERS :
- task : string, which is the file name of the scilab script (see exec) to be
started. The Scilab script must already reside on the host on which it
is to be started. The name must an absolute path.
- ntask
: integer, specifying the number of copies of the scilab script to start.
- where
: string (optional), can be a host name such as ``tequila.ens-lyon.fr'' or a PVM architecture class such as ``SUN4''.
- numt
: integer, the actual number of tasks started.
Values less than zero indicate a system error.
tids
: row of integers, array of the tids of the PVM processes started
by this pvm_spawn call.
DESCRIPTION :
pvm_spawn starts
ntask
copies of the scilab script
task.
On systems that support environment,
spawn passes selected variables from parent environment to children tasks.
If set, the envar PVM_EXPORT is passed.
If PVM_EXPORT contains other names (separated by ':') they will
be passed too. This is useful for e.g.:
setenv DISPLAY myworkstation:0.0
setenv MYSTERYVAR 13
setenv PVM_EXPORT DISPLAY:MYSTERYVAR
The hosts on which
the PVM processes are started are determined by
the
where
arguments. On return the array
tids
contains the PVM task identifiers for each process started.
If pvm_spawn starts one or more tasks,
numt
will be the actual number of tasks started.
If a system error occurs then
numt
will be < 0.
If
numt
is less than
ntask
then some executables
have failed to start and the user should check the last
ntask -
numt
locations in the
tids
array which will contain error codes
(see below for meaning).
The first
numt
tids in the array are always valid.
When
the argument
where
is omitted a heuristic (round-robin assignment) is used to distribute the
ntask
processes across the virtual machine.
In the special case where a multiprocessor is specified by
where,
pvm_spawn will start all
ntask
copies on this
single machine using the vendor's underlying routines.
EXAMPLE :
// create an exec file (script)
write(TMPDIR+'/foo.sce',['a=1';'plot2d()'])
// start a new Scilab on the same host to execute the script
[tids, numt] = pvm_spawn(TMPDIR+'/foo.sce',1)
pvm_kill(tids) //terminate the new scilab
See Also :
pvm X, pvm_spawn_independent X
22.24 pvm_spawn_independent Starts new PVM processes.
CALLING SEQUENCE :
[tids, numt] = pvm_spawn_independent(task, ntask, [where])
PARAMETERS :
- task:
string, which is the executable file name of the PVM process to
be started. The executable must already reside on the host on which it
is to be started. The name may be a file in the PVM search path or an
absolute path. The default PVM search path is
$HOME/pvm3/bin/$PVM_ARCH/ .
- ntask:
integer, specifying the number of copies of the executable file
to start.
- where:
string (optional), can be a host name
such as ``tequila.ens-lyon.fr'' or a PVM architecture class such as
``SUN4''.
- numt:
integer, the actual number of tasks started. Values less than
zero indicate a system error.
tids:
row of integers, array of the tids of the PVM processes started
by this pvm_spawn_independent call.
DESCRIPTION :
pvm_spawn_independent starts
ntask
copies of the executable named
task.
On systems that support environment, spawn passes selected variables
from parent environment to children tasks. If set, the envar
PVM_EXPORT is passed. If PVM_EXPORT contains other names
(separated by ':') they will be passed too. This is useful for e.g.:
setenv DISPLAY myworkstation:0.0
setenv MYSTERYVAR 13
setenv PVM_EXPORT DISPLAY:MYSTERYVAR
The hosts on which the PVM processes are started are determined by the
where
arguments. On return the array
tids
contains the PVM task identifiers for each process started.
If pvm_spawn_independent starts one or more tasks,
numt
will be the actual number of tasks started. If a system error occurs
then
numt
will be < 0.
If
numt
is less than
ntask
then some executables have failed to start and the user should check
the last
ntask -
numt
locations in the
tids
array which will contain error codes (see below for meaning). The
first
numt
tids in the array are always valid.
When the argument
where
is omitted a heuristic (round-robin assignment) is used to
distribute the
ntask
processes across the virtual machine.
In the special case where a multiprocessor is specified by
where,
pvm_spawn_independent will start all
ntask
copies on this single machine using the vendor's underlying routines.
EXAMPLE :
[tids, numt] = pvm_spawn_independent("a.out",2)
See Also :
pvm X, pvm_spawn X
22.25 pvm_start Start the PVM daemon
CALLING SEQUENCE :
[info] = pvm_start()
PARAMETERS :
- info
: integer, status code returned by the routine.
Values less than zero indicate an error.
DESCRIPTION :
pvm_start starts the Pvmd3 which is a daemon process which
coordinates unix hosts in a virtual machine. One pvmd3 must run on
each host in the group. They provide the communication and process
control functions needed by the user's PVM processes. The local and
remote pvmds can also be started from the PVM console program pvm.
For example:
pvm_start()
ans =
0.
-->pvm_start()
ans =
- 28.
Error -28 means: pvm_start_pvmd(): Duplicate host
See Also :
pvm_halt X, pvm_addhosts X, pvm_config X
22.26 pvm_tasks returns information about the tasks running
on the virtual machine.
CALLING SEQUENCE :
res = pvm_tasks([where 0])
PARAMETERS :
DESCRIPTION :
pvm_tasks returns information about
tasks presently running on the virtual machine.
The information returned is the same as
that available from the console command
ps.
The pvm_tasks function returns information about the entire
virtual machine in one call.
If pvm_tasks is successful,
info
will be 0.
If some error occurs then
info
will be < 0.
for example:
-->res = pvm_tasks()
res =
res(1)
! 262148. 262151. 262152. !
res(2)
! 262147. 0. 262151. !
res(3)
! 262144. 262144. 262144. !
res(4)
! 6. 4. 6. !
res(5)
!pvmgs /home/ubeda/SCILAB/scilab-2.4/bin/scilex !
res(6)
3.
res(7)
0.
See Also :
pvm_config X, pvm_tidtohost X
22.27 pvm_tidtohost returns the host of the specified PVM process.
CALLING SEQUENCE :
[dtid] = pvm_tidtohost(tid)
PARAMETERS :
- tid
: integer, task identifier of the PVM process in question.
- dtid
: integer, the tid of the host's pvmd3
or a negative value if an error.
DESCRIPTION :
pvm_tidtohost returns the host id on which the process identified by
tid is located.
EXAMPLE :
dtid = pvm_tidtohost(pvm_mytid())
See Also :
pvm_config X, pvm_tasks X
22.28 pvmd3 PVM daemon
SYNOPSIS :
pvmd3 [ -options ] [ hostfile ] &
DESCRIPTION :
pvmd3 is a daemon process which coordinates hosts in a virtual
machine. One pvmd must run on each host in the group. They provide
the communication and process control functions needed by the user's
PVM processes. The daemon can be started manually with a host file
argument that will automatically start the remote pvmds. The local and
remote pvmds can also be started from the PVM console program pvm.
The name of the daemon executable is pvmd3. It is usually started by a
shell script, $PVM_ROOT/lib/pvmd.
Local daemon may also be started by the scilab instruction pvm_start()
and remote daemons may also be started by the scilab function
pvm_addhosts
OPTIONS :
The following options may be specified on the command line when
starting the master pvmd or PVM console:
- -
dmask Set pvmd debug mask. Used to debug the pvmd or libpvm (not
intended to be used to debug application programs). Mask is a
hexadecimal number which is the sum of the following bits: Bit
Information
1
- 1
Packet routing
- 2
Message routing and entry points
- 4
Task management
- 8
Slave pvmd startup
- 10
Host table updates
- 20
Select loop (below packet layer)
- 40
IP network
- 80
Multiprocessor port debugging
- 100
Resource manager interface
- 200
Application (messages with no destination, etc.)
0
- -nname
Specify an alternate hostname for the master pvmd to use. Useful when
gethostname() returns a name not assigned to any network interface.
The following options are used by the master pvmd when starting slaves
and are only of interest to someone writing a hoster. Don't just go
using them, now.
- -s
Start pvmd in slave mode. Hostfile cannot be used, five additional
parameters must be supplied: master pvmd index, master IP, master MTU,
slave pvmd index, and slave IP.
- -S
Same as -s, but slave pvmd doesn't wait for its stdin to be closed
after printing its parameters. Used for manual startup.
- -f
Slave doesn't fork after configuration (useful if the slave is to
be controlled or monitored by some process).
Lines beginning with a splat ( # ), optionally preceded by whitespace,
are ignored.
-1
A simple host file might look like:
# my first host file
thud
fred
wilma
barney
betty
This specifies the names of five hosts to be configured in the virtual
machine.
The master pvmd for a group is started by hand on the localhost, and
it starts slaves on each of the remaining hosts using the rsh or rexec
command. The master host may appear on any line of the hostfile, but
must have an entry.
The simple format above works fine if you have the same login name on
all five machines and the name of the master host in your .rhosts
files on the other four.
There are several host file options available:
- lo=NAME
Specifies an alternate login name (NAME) to use.
- so=pw
This is necessary when the remote host cannot trust the
master. Causes the master pvmd to prompt for a password for the remote
host in the tty of the pvmd (note you can't start the master using the
console or background it when using this option) you will see:
Password (honk.cs.utk.edu:manchek): you should type your password for
the remote host. The startup will then continue as normal.
- dx=FILE
Specifies the path of the pvmd executable. FILE may be a
simple filename, an absolute pathname, or a path relative to the
user's home directory on the remote host. This is mainly useful to aid
in debugging new versions of PVM, but may have other uses.
- ep=PATH
Specifies a path for the pvmd to search for executable program
components when spawning a new process. The path may have multiple
elements, separated by colons ( : ).
- wd=PATH Specifies a working directory in which all spawned tasks on
this host will execute.
- sp=VALUE
Specifies the relative computational speed of this host
compared to other hosts in the configuration. VALUE is an integer in
the range [1 - 1000000]
- bx=PATH
Specifies the debugger program path. Note: the environment
variable PVM_DEBUGGER can also be set.
- so=ms
Rarely used. Causes the master pvmd to request user to manually
perform the startup of a pvmd on a slave host when rsh and rexec
network services are disabled but IP connectivity exists. See section
"MANUAL STARTUP".
-2
A dollar sign ( $ ) in an option introduces a variable name, for
example $PVM_ARCH. Names are expanded from environment variables by
each pvmd.
Each of the flags above has a default value. These are:
- lo
The loginname on the master host.
- so
Nothing
- dx
$PVM_ROOT/lib/pvmd (or environment variable PVM_DPATH)
- ep
pvm3/bin/$PVM_ARCH:$PVM_ROOT/bin/$PVM_ARCH
- wd
$HOME
- sp
1000
- bx
$PVM_ROOT/lib/debugger
-3
You can change these by adding a line with a star ( * ) in the first
field followed by the options, for example:
- * lo=afriend so=pw
This sets new default values for `lo' and `so' for the remainder of
the host file, or until the next `*' line. Options set on the last `*'
line also apply to hosts added dynamically using pvm_addhosts().
Host options can be set without starting the hosts
automatically. Information on host file lines beginning with `&' is
stored, but the hosts are not started until added using
pvm_addhosts().
Example hostfile:
# hostfile for testing on various platforms fonebone
refuge
# installed in /usr/local/here
sigi.cs
dx=/usr/local/pvm3/lib/pvmd # borrowed accts, "guest", don't trust fonebone
- * lo=guest so=pw sn666.jrandom.com cubie.misc.edu # really painful one, must start it by
hand and share a homedir & igor.firewall.com lo=guest2 so=ms
ep=bob/pvm3/bin/$PVM_ARCH
MANUAL STARTUP :
When adding a host with this option set you will see on the tty of the
pvmd:
*** Manual startup ***
Login to "honk" and type:
$PVM_ROOT/lib/pvmd -S -d0 -nhonk 1 80a9ca95:0cb6 4096 2 80a95c43:0000 Type response:
after typing the given command on host honk, you should see a line
like:
ddpro<2312> arch<ALPHA> ip<80a95c43:0a8e> mtu<4096>
type this line on the tty of the master pvmd. You should then see:
Thanks
and the two pvmds should be able to communicate.
Note you can't start the master using the console or background it
when using this option.
STOPPING PVMD3 :
The preferred method of stopping all the pvmds is to give the halt
command in the PVM console. This kills all pvm tasks, all the remote
daemons, the local daemon, and finally the console itself. If the
master pvmd is killed manually it should be sent a SIGTERM signal to
allow it to kill the remote pvmds and clean up various files.
The pvmd can be killed in a manner that leaves the file /tmp/pvmd.uid
behind on one or more hosts. Uid is the numeric user ID (from
/etc/passwd) of the user. This will prevent PVM from restarting on
that host. Deletion of this file will fix this problem:
rm `( grep $user /etc/passwd || ypmatch $user passwd ) | \\
awk -F: `{print "/tmp/pvmd."$3; exit}'`
22.29 Communications communications with other applications using GeCi
DESCRIPTION :
This the beta version of the Communications Toolbox.
GeCi manages communications between Scilab and other applications (included
Scilab itself) by using GeCi.
GeCI is an interactive communication manager created in order to
manage remote executions of softwares and allow exchanges of messages
between those softwares. It offers the possibility to exploit numerous
machines on a network, as a virtual computer, by creating a
distributed group of independent softwares.
In order to communicate, the other applications must have been prepared for,
by including a communication library in them. The way to do this is described
in the Communication Toolbox documentation.
See Also :
CreateLink X, DestroyLink X, ExecAppli X, GetMsg X, SendMsg X, WaitMsg X
22.30 CreateLink creates a link between two applications
CALLING SEQUENCE :
CreateLink(appli1,appli2)
PARAMETERS :
- appli1, name of an application
: string
- appli2
: string, name of an application
DESCRIPTION :
CreateLink creates a link from appli1 to appli2.
Note that this link is directed.
This link being created, appli1 can send messages to appli2 and
appli2 can receive messages from appli1.
If the name of appli1 or appli2 is "SELF", it corresponds
to the name of the application where we execute CreateLink.
If the name of appli1 or appli2 is "XGeCI", it corresponds
to the name of the first Scilab application started.
See Also :
DestroyLink X, GetMsg X, SendMsg X
22.31 DestroyLink destroys the link between two applications
CALLING SEQUENCE :
DestroyLink(appli1,appli2)
PARAMETERS :
- appli1, name of an application
: string
- appli2
: string, name of an application
DESCRIPTION :
DestroyLink destroys the link from appli1 to appli2.
If the name of appli1 or appli2 is "SELF", it corresponds
to the name of the application where we execute DestroyLink.
If the name of appli1 or appli2 is "XGeCI", it corresponds
to the name of the first Scilab application started.
See Also :
CreateLink X
22.32 ExecAppli executes an application
CALLING SEQUENCE :
ExecAppli(command,h,appli)
PARAMETERS :
- command
: string, command of the application
- h
: string, host name
- appli
: string, name of the application
DESCRIPTION :
ExecAppli executes the application described by command on the host h and gives it the name appli.
Arguments of the application can be also given in the string command.
After executing ExecAppli, it is necessary to create links with
CreateLink to be able to send messages between applications.
EXAMPLE :
h=unix_g("hostname")
ExecAppli(SCI+"/bin/scilex",h,"Scilab2")
CreateLink("SELF","Scilab2")
ExecAppli(SCI+"/bin/scilex -ns",h,"Scilab3")
See Also :
CreateLink X, ExecScilab X, ExeclScilab X
22.33 ExecScilab executes another local Scilab
CALLING SEQUENCE :
ExecScilab(appli)
PARAMETERS :
- appli
: string, name of new Scilab
DESCRIPTION :
ExecScilab executes a new Scilab application on the same host.
After executing ExecScilab, it is necessary to create links with
CreateLink to be able to send messages to new Scilab.
Use ExecAppli to execute a new Scilab application on a remote host.
See Also :
CreateLink X, ExecAppli X, ExeclScilab X
22.34 ExeclScilab executes another linked local Scilab
CALLING SEQUENCE :
ExeclScilab(appli)
PARAMETERS :
- appli
: string, name of new Scilab
DESCRIPTION :
ExecScilab executes a new Scilab application on the same host and
creates links between them.
Use ExecAppli to execute a new Scilab application on a remote host.
See Also :
CreateLink X, ExecAppli X, ExecScilab X
22.35 GetMsg gets a pending message
CALLING SEQUENCE :
[type,msg,appli] = GetMsg()
PARAMETERS :
- type
: string
- msg
: string
- appli
: string, name of an application
DESCRIPTION :
GetMsg gets, in an asynchronous way, a message sent by another
application.
The type of the message is string and the message itself is
msg.
The name of the application which has sent the message is appli,
See Also :
SendMsg X, WaitMsg X
22.36 SendMsg sends a message
CALLING SEQUENCE :
SendMsg(type,msg)
PARAMETERS :
- type
: string
- msg
: string
DESCRIPTION :
SendMsg sends a message to ALL applications linked to this application.
See Also :
CreateLink X, SendMsg X, WaitMsg X
22.37 WaitMsg waits for a message
CALLING SEQUENCE :
[type,msg] = WaitMsg(appli)
PARAMETERS :
- appli
: string, name of an application
- type
: string
- msg
: string
DESCRIPTION :
WaitMsg waits for a message sent by another application.
As long as any message has not been sent, WaitMsg waits.
This is a way to send and get messages in a synchronous way.
The type of the message is string and the message itself is
msg.
By default the name of the first application (the one executed by GeCi) is
"XGeCI".
See Also :
GetMsg X, SendMsg X