MPI_Info_put (INOUT InfoHandle, IN ElementName, IN ElementValue)
MPI_Info_get (INOUT InfoHandle, IN ElementName, OUT ElementValue, OUT Flag)
C Bindings:
MPI_Info_create(MPI_Info *)
MPI_Info_put(MPI_Info, char *, char *)
MPI_Info_get(MPI_Info, char *, char *, int *)
MPI_Info_dup(MPI_Info, MPI_Info *)
MPI_Info_delete(MPI_Info *)
I think some things like this showed up in the dynamic chapter,
but were not expressed like getenv/putenv.
Leslie
With this approach I can imagine intercepting the IO calls (eg MPI_Open,
MPI_Read, ... (whatever names we choose)) using the profiling interface.
When in open I can inspect the info argument (using MPI_Info_get) for a
special indicator to use my protocol. If I find an indicator for my protocol,
I cache something in the file handle (or comm or whatever we decide represents
a file), if I don't find something I call PMPI_Open. My $0.02
So, does this belong in misc??
------- Forwarded Message
I agree that some unification here would be very nice. For example, we now have
a new interface for building INFO handles when we want to spawn, and we have
just decided that these should be constructed out of {key,value} strings. But
we have no such interface for building the cmd line arrays, which is a real
wart. All of this nonsense is only needed because we care about FORTRAN
strings, so that's probably the right abstraction to use, I think. So how about
the following:
MPI_String_create(MPI_String *)
MPI_String_append(MPI_String *, char *)
MPI_String_dup(MPI_String, MPI_String *)
MPI_String_delete(MPI_String *)
This would allow us to build both key/val pairs and command lines, since we can
just pass "key=val" strings where appropriate.
- --
Eric Salo Silicon Graphics Inc. "Do you know what the
(415)933-2998 2011 N. Shoreline Blvd, 7L-802 last Xon said, just
salo@sgi.com Mountain View, CA 94043-1389 before he died?"
------- End of Forwarded Message