> My application is started from an NQS job, and inherits resource
> limits the job. I would like to further qualify the resources
> for the mpi application. Lets take a simple one, like limiting
> it to machines where I have an account. I call the resource
> manager interface with my NQS job limits, and my account name
> as a restriction. I get back a description as a data
> structure that combines my job limits with the restriction of
> only where I have an account.
>
> Now.....I want to give that information to
> mpi_spawn(). Do I have to translate this information into
> a character string? That isn't desirable in this situation.
Definitely an issue. Here's how I think about it.
In either case (void* or char*),
1. The MPI implementation will have to understand NQS very well
2. The application will not be portable
That's ok -- we accepted these when we added the info argument.
However, I assert that it also means:
1. Even with (void *) pointer, the implementation will have
to understand its internal structure. It will probably not be able to
pass it through to the underlying resource/process controller without
looking at it and understanding it.
2. Though parsing a string is a bit more difficult than
looking at a structure, it is basically easy.
3. As long as the application is not portable, it might as well
have a function cri_nqs_convert_struct_to_mpi_info(IN struct, OUT info).
Adding that won't reduce portability.
> I understand that a character string could promote some minimal
> level of interoperability, but if it prevents interfacing with
> more intelligent resource managers then I think the restriction
> is too large.
Check out 3.4.6, whose intent was to promote actually a fair
amount of interoperability. Does it go too far?
Does a character string actually *prevent* interfacing
with more intelligent resource managers or just make it
more difficult?
> A possible solution.
>
> A handle is passed to mpi_spawn(). MPI defines the handle to
> be the following:
>
> handle---> flag
> char *
> void *
>
>
> The flag could specify whether or not the char * data or the
> void * data should be used by a resource manager. A strictly
> portable program could use the char * as its only means
> passing information into mpi_spawn(). However, a more complex
> interface to a resource manager may be used by passing information
> in the void *. We could even go so far as to say that all implementations
> must support some minimal character string format.
Starting to get a bit too complicated for me - I'd prefer
just void* (which can also handle strings) if we go this route.
> Another possibility:
> Specify only a void pointer. The argument against this is that
> fortran is a problem. However, in Fortran 90 there is a concept
> of overloading such that you can provide different functions
> for different datatypes. For example,
> mpi_spawn (....., character *, ....)
> could be mapped to mpi_spawn_char() and
> mpi_spawn (......., void *, ......)
> could be mapped to mpi_spawn_void(). The names mpi_spawn_char and
> mpi_spawn_void wouldn't be used by the programmer, but would
> instead be internal to the f90 interface.
My first comment is that we shouldn't feel bad about making
Fortran users suffer in this case. The second comment is that
I don't think Fortran90 overloading can work as you've
described. Unfortunately there's no "void *" in Fortran 90.
You need a specific type. That type has to be
known in advance - there must be an interface block in the mpi
module and there must be a corresponding function defined
in the library. There's no possibility of Fortran 90
looking at the arguments on the fly. Also, I would be very suspect
of any claims that there will ever exist a resource manager
that will return a Fortran 90 derived type!
Bill