I believe the problem is designing a "smart" interface that would work
with a gamut of schedulers. For example, if MPI endorsed an interface
which worked with (for example) an NQS manager, then mpi_spawn() would
immediately become non-portable to non-NQS environments.
For now a reasonable approach would be to rely on something very basic and
grundgy. If interfacing to an NQS (or LoadLeveler, or whatever) manager
becomes important, then an ISV or academic effort will produce an
MPIXXX_resource_encoder() function to convert structs to char strings and
visa versa. If the scheduling community can define a semblence of an API
standard, then MPI could consider supporting it in a newly named "spawn"
function.
Getting the MPI Forum involved in other (job scheduler) standards is
perhaps too much to ask .. but having the Forum contribute a report on its
estimate of what's needed in future external standards efforts is probably
a good idea.
Other opinions?
- Richard
On Mon, 22 Apr 1996, Laurie Costello wrote:
>
> Hi,
>
> Sorry this is so late....but better late than never. I'm not
> able to attend the meeting this week, so if you can comment
> via email, I can discuss it with Heidi who will be attending
> the meeting before she leaves.
>
> Thanks,
> Laurie
>
>
>
> Another opinion on char * versus void *:
> ---------------------------------------
>
>
> Here's the problem I have with the interface of only a char *.
>
> 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.
>
> 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.
>
>
> 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.
>
> I think this fits with MPI goals of performance and portability.
> A completely portable application could use the character string
> to specify simple requirements. To ensure that we work with
> any resource manager, and thus provide the best performance, we
> also provide a way of getting the information via a handle.
>
> Of course.....keeping with tradition, an additional function would
> be added to setup the handle!
>
> mpi_setup_resource_handle(MPI_Aint handle, integer flag,
> char *char_resource_data, void *resource_data)
>
>
> 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.
>
>
>