1. Section 3.3.4 MPI_SPAWN_INDEPENDENT
Supporting NON-MPI processes seemed outside the scope of an MPI spec. Isn't
this type of activity usually provided in Generic Middleware?
2. Section 3.6.4
MPI_INFO_FREE - frees the handle created by MPI_INFO_CREATE or MPI_INFO_ADD.
In the case of MPI_INFO_ADD, and MPI_SPAWN, can a flag be set to either
free or not free the handle. If the flag is set, MPI_INFO_FREE could be
called automatically.
This could solve the problem of multiple SPAWN calls, but probably stretches
the rules a bit. On the positive side, it reduces the need for string
duplicating functions.
3. Section 3.6.5
If the MPI_NONMPI flag is set and the process becomes an MPI process
automatically, this seems like the opposite of the definition in
section 3.3.4.
The comments in 1 and 3 above follow the idea that perhaps wherever
an implementation detail is required, it would be best not to bump it
up into the MPI functions if possible, but instead handle it as
a recomendation to implementor & user. This follows another thought
that has been bounced to me from a wide community - we do not
want MPI to become so complex that it is confusing to use.
Regards, Anna
-----------------------------------------------------------------------------
Anna Rounbehler
SKY Computer
27 Industrial Avenue
Chelmsford, MA. 01824
rounbehler@sky.com
(508) 250-1920 ex 248