My idea of automatic freeing is the following:
handle = MPI_STRING_NULL; /* handle of an empty string */
MPI_String_add ( &handle, string); /* handle is changed */
MPI_Spawn (... &handle, ....); /* handle is freed,
i.e. handle == MPI_STRING_NULL */
Additional functions -- normally not necessary:
MPI_String_dup (in_handle, &out_handle); /* duplication */
MPI_String_get (in_handle, index, max_length, &out_string)
MPI_String_Num (in_handle, out_num);
MPI_String_free (&in_handle);
Simple things should be simply programmable.
Because with this interface the %%-algorithm is not necessary
and because normal applications have some effort to concatenate
multi-term info arguments, one can say that this interface is not
more complicated than the current string interface.
I think Al Geists proposal, to define the "info-handle-routines"
in a general way like "string-handle-routines"
is good.
Then we can decide independently if we want to use them
for
- info -- or --
- info & command-line
I think the idea to automaticly free the handle at the next usage
is the key to get an easily usable interface.
> This would simplify
> the interface for a single spawn call, but would complicate it if a user
> wanted to set up the info argument, then do multiple spawns, reusing
> the info argument. Since MPI_SPAWN would free the handle, the user would
> have to make another MPI_INFO_CREATE call ahead of time to duplicate the
> handle.
With the proposal above, the user must only add a MPI_String_dup
at the right place -- with Heidi's proposal the user must call
MPI_INFO_FREE for each handle created on the road of a composition
of a multi-term info argument and each MPI_INFO_ADD on this road
does logically a duplication of the old_handle and then the addition
of the new string.
Rolf
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de
--------------------------------
>
>After adding my two cents about the new MPI_SPAWN() proposal, I would also
>like to propose the following change to the info argument to MPI_SPAWN()
>(for either the new or current proposals.)
>
>As currently stated in the proposal, the info argument is opaque to MPI
>and is directly passed to the runtime environment, which uses it to
>determine where and how to spawn processes. If the info argument is
>empty, the runtime environment decides where to spawn processes. Portable
>programs not requiring detailed control over process locations should use
>an empty argument.
>
>MPI does not specify the format of the info argument, which is left
>up to the MPI implementation. The format is expected to be tailored
>to the particular runtime system being used.
>
>Because the format can be tailored to a particular system, and
>is left up to the implementation, the info argument should be
>general enough to allow programs to pass information to runtime
>environments with different levels of sophistication.
>
>I would like to propose that the info argument to MPI_SPAWN is a handle.
>
>The following functions would be added to create/free the handle:
>
> MPI_INFO_CREATE(info, handle)
> IN info a string providing information to
> the runtime system on how/where to
> start processes
> OUT handle MPI_INFO_HANDLE
>
> MPI_INFO_ADD(old_handle, info, new_handle)
> IN old_handle MPI_INFO_HANDLE
> IN info string providing additional information on
> how/where to start processes
> OUT new_handle MPI_INFO_HANDLE
>
> MPI_INFO_FREE(handle)
> IN handle MPI_INFO_HANDLE
>
>The following is a variable defined for both C and Fortran to be used
>when a program passes info as an empty argument:
>
> MPI_INFO_NULL
>
>
>Discussion
>----------
>
>The original proposal defines info as a string. This proposal has
>fewer functions, but is less flexible. Another drawback with having
>info as a string, is that info is limited on some systems to 256 characters
>in Fortran, and the possibility of users specifying a string with more
>that 256 characters is quite feasible.
>
>The new proposal allows more flexibility. Users can still pass a string,
>and can add to it, solving the 256 character string length problem.
>It also allows more complex information in the form of structures
>for example, to be passed to the runtime environment. The new proposal
>also defines MPI_INFO_NULL so that users can easily pass an empty
>argument from either Fortran or C.
>
>Rolf suggested to me that the MPI_INFO_ADD() and MPI_SPAWN functions free
>the handle instead of having a separate function. This would simplify
>the interface for a single spawn call, but would complicate it if a user
>wanted to set up the info argument, then do multiple spawns, reusing
>the info argument. Since MPI_SPAWN would free the handle, the user would
>have to make another MPI_INFO_CREATE call ahead of time to duplicate the
>handle.
>
>
>Comments? %:)
>
>
>Heidi Poxon E-Mail: hlg@cray.com
>Cray Research, Inc. Phone: 612/683-5677
>655F Lone Oak Drive
>Eagan, MN 55121
>
Rolf Rabenseifner (Computer Center )
Rechenzentrum Universitaet Stuttgart (University of Stuttgart)
Allmandring 30 Phone: ++49 711 6855530
D-70550 Stuttgart 80 FAX: ++49 711 6787626
Germany rabenseifner@rus.uni-stuttgart.de