Subject: Re: MPI_INIT

From: [email-masked]
Date: Mon, 8 Mar 93 17:00:38 PST

Jon Flower says:

> Also, in Rik's example, I think the code has to look sort of
> like
> 
> 	main(argc, argv)
> 	int argc;
> 	char **argv;
> 	{
> 		MPI_INIT(&argc, &argv);
> 		FOO_INIT(&argc, &argv);
> 			/* etc... */

Yeah, sort of.  The example I showed was based on one version of
current practice (TCGMSG).  It doesn't let the INIT's alter the
argument list.  In general, this implies far worse ugliness than
Jon's example, because it requires that applications know enough
to ignore arguments intended for the INIT's.  

A better version of current practice is the X window system, one
of whose initializers looks like

  XtInitialize ( ... &argc, argv)

This allows deleting stuff from the argument list, but not adding.

Jon's syntax goes farther and allows both.

But maybe this is working the wrong issue.

I said:

> A minor problem with the static boolean suggestion is that then the
> initialization routine does not have access to those parts of the
> environment passed as (argc,argv).  Such access is sometimes useful.

It could also be said that the problem is with the (argc,argv) approach.

I defended the (argc,argv) approach, sort of, but I confess that
I don't like it very much precisely because it DOES prevent
calling the MPI initializer from inside some other routine.  I
ran afoul of this just a few days ago, when I tried to emulate
another package using TCGMSG, and discovered that my application
called the other package's initializer from several procedures
down.

What I would *really* like (putting on my user's hat),
is an explicit MPI_INIT with no arguments, like Jon suggests.

I guess this means that implementors have to find some way to
pass environment info other than through the argv list.  Can
anyone come up with a convincing reason why this is a big problem?

--Rik Littlefield