mpid_init.tex

刚才是说明 现在是安装程序在 LINUX环境下进行编程的MPICH安装文件

\startmanpage
\mantitle{MPID{\tt \char`\_}Init}{tex}{10/7/2002}
\manname{MPID{\tt \char`\_}Init}
--- Initialize the device 
\subhead{Synopsis}
\startvb\begin{verbatim}
int MPID_Init( int *argc_p, char *(*argv_p)[], 
               int requested, int *provided,
               MPID_Comm **parent_comm, int *has_args, int *has_env )

\end{verbatim}
\endvb

\subhead{Input Parameters}
\startarg{argc{\tt \char`\_}p }{Pointer to the argument count
}
\startarg{argv{\tt \char`\_}p }{Pointer to the argument list
}
\startarg{requested }{Requested level of thread support.  Values are the same as
for the {\tt required} argument to {\tt MPI{\tt \char`\_}Init{\tt \char`\_}thread}, except that we define
an enum for these values.
}
\par
\subhead{Output Parameter}
\startarg{provided }{Provided level of thread support.  May be less than the 
requested level of support.
}
\startarg{parent{\tt \char`\_}comm }{{\tt MPID{\tt \char`\_}Comm} of parent.  This is null for all MPI-1 uses and 
for processes that are {\em not} started with {\tt MPI{\tt \char`\_}Comm{\tt \char`\_}spawn} or 
{\tt MPI{\tt \char`\_}Comm{\tt \char`\_}spawn{\tt \char`\_}multiple}.
}
\startarg{has{\tt \char`\_}args }{Set to true if {\tt argc{\tt \char`\_}p} and {\tt argv{\tt \char`\_}p} contain the command
line arguments.  See below.
}
\startarg{has{\tt \char`\_}env  }{Set to true if the environment of the process has been 
set as the user expects.  See below.
}
\par
\subhead{Return value}
Returns {\tt 0} on success and an MPI error code on failure.  Failure can happen
when, for example, the device is unable to start or contact the number of
processes specified by the {\tt mpiexec} command.
\par
\subhead{Notes}
Null arguments for {\tt argc{\tt \char`\_}p} and {\tt argv{\tt \char`\_}p} {\em must} be valid (see MPI-2, section
4.2)
\par
Multi-method devices should initialize each method within this call.
They can use environment variables and/or command-line arguments
to decide which methods to initialize (but note that they must not
{\em depend} on using command-line arguments).
\par
This call also initializes all MPID data needed by the device.  This
includes the {\tt MPID{\tt \char`\_}Request}s and any other data structures used by
the device.
\par
The arguments {\tt has{\tt \char`\_}args} and {\tt has{\tt \char`\_}env} indicate whether the process was
started with command-line arguments or environment variables.  In some
cases, only the root process is started with these values; in others,
the startup environment ensures that each process receives the
command-line arguments and environment variables that the user expects.
While the MPI standard makes no requirements that command line arguments or
environment variables are provided to all processes, most users expect a
common environment.  These variables allow an MPI implementation (that is
based on ADI-3) to provide both of these by making use of MPI communication
after {\tt MPID{\tt \char`\_}Init} is called but before {\tt MPI{\tt \char`\_}Init} returns to the user.
\par
This routine is used to implement both {\tt MPI{\tt \char`\_}Init} and {\tt MPI{\tt \char`\_}Init{\tt \char`\_}thread}.
\par
Setting the environment requires a {\tt setenv} function.  Some
systems may not have this.  In that case, the documentation must make
clear that the environment may not be propagated to the generated processes.
\par
The {\tt parent{\tt \char`\_}comm} argument may not be the right interface.
\par
\subhead{Module}
MPID{\tt \char`\_}CORE
\par
\subhead{Questions}
\par
The values for {\tt has{\tt \char`\_}args} and {\tt has{\tt \char`\_}env} are boolean.
They could be more specific.  For
example, the value could indicate the rank in {\tt MPI{\tt \char`\_}COMM{\tt \char`\_}WORLD} of a
process that has the values; the value {\tt MPI{\tt \char`\_}ANY{\tt \char`\_}SOURCE} (or a {\tt -1}) could
indicate that the value is available on all processes (including this one).
We may want this since otherwise the processes may need to determine whether
any process needs the command line.  Another option would be to use positive
values in the same way that the {\tt color} argument is used in {\tt MPI{\tt \char`\_}Comm{\tt \char`\_}split};
a negative value indicates the member of the processes with that color that
has the values of the command line arguments (or environment).  This allows
for non-SPMD programs.
\par
Do we require that the startup environment (e.g., whatever {\tt mpiexec} is
using to start processes) is responsible for delivering
the command line arguments and environment variables that the user expects?
That is, if the user is running an SPMD program, and expects each process
to get the same command line argument, who is responsible for this?
The {\tt has{\tt \char`\_}args} and {\tt has{\tt \char`\_}env} values are intended to allow the ADI to
handle this while taking advantage of any support that the process
manager framework may provide.
\par
Can we fix the Fortran command-line arguments?  That is, can we arrange for
{\tt iargc} and {\tt getarg} (and the POSIX equivalents) to return the correct
values?  See, for example, the Absoft implementations of {\tt getarg}.
We could also contact PGI about the Portland Group compilers, and of
course the {\tt g77} source code is available.
Does each process have the same values for the environment variables
when this routine returns?
\par
If we don't require that all processes get the same argument list,
we need to find out if they did anyway so that {\tt MPI{\tt \char`\_}Init{\tt \char`\_}thread} can
fixup the list for the user.  This argues for another return value that
flags how much of the environment the {\tt MPID{\tt \char`\_}Init} routine set up
so that the {\tt MPI{\tt \char`\_}Init{\tt \char`\_}thread} call can provide the rest.  The reason
for this is that, even though the MPI standard does not require it,
a user-friendly implementation should, in the SPMD mode, give each
process the same environment and argument lists unless the user
explicitly directed otherwise.
\par
How does this interface to BNR?  Do we need to know anything?  Should
this call have an info argument to support BNR?
\par
The following questions involve how environment variables and command
line arguments are used to control the behavior of the implementation.
Many of these values must be determined at the time that {\tt MPID{\tt \char`\_}Init
}is called.  These all should be considered in the context of the
parameter routines described in the MPICH2 Design Document.
\par
Are there recommended environment variable names?  For example, in ADI-2,
there are many debugging options that are part of the common device.
In MPI-2, we can't require command line arguments, so any such options
must also have environment variables.  E.g., {\tt MPICH{\tt \char`\_}ADI{\tt \char`\_}DEBUG} or
{\tt MPICH{\tt \char`\_}ADI{\tt \char`\_}DB}.
\par
Names that are explicitly prohibited?  For example, do we want to
reserve any names that {\tt MPI{\tt \char`\_}Init{\tt \char`\_}thread} (as opposed to {\tt MPID{\tt \char`\_}Init})
might use?
\par
How does information on command-line arguments and environment variables
recognized by the device get added to the documentation?
\par
What about control for other impact on the environment?  For example,
what signals should the device catch (e.g., {\tt SIGFPE}? {\tt SIGTRAP}?)?
Which of these should be optional (e.g., ignore or leave signal alone)
or selectable (e.g., port to listen on)?  For example, catching {\tt SIGTRAP
}causes problems for {\tt gdb}, so we'd like to be able to leave {\tt SIGTRAP
}unchanged in some cases.
\par
Another environment variable should control whether fault-tolerance is
desired.  If fault-tolerance is selected, then some collective operations
will need to use different algorithms and most fatal errors detected by the
MPI implementation should abort only the affected process, not all processes.
\endmanpage