Maybe?? It would help avoid the unexpected behavior problem, but may ultimately be too unwieldy for widespread adoption. Still, an option to ponder.
On Apr 3, 2014, at 9:27 AM, Kenneth A. Lloyd <kenneth.ll...@wattsys.com> wrote: > Would you consider a user-defined process language library outside of > OpenMPI? Process functors could be defined by compositions in this external > area, and maintenance of the language simply the user's responsibility? > > -----Original Message----- > From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain > Sent: Thursday, April 03, 2014 8:17 AM > To: Open MPI Developers > Subject: Re: [OMPI devel] [OMPI svn] svn:open-mpi r31302 - in trunk: > opal/mca/base orte/tools/orterun > > I can see the potential utility, but I do have concerns about how to make it > work without causing a lot of user problems: > > * as currently implemented, it only affects procs launched via mpirun. This > seems odd - if the user does a direct launch, they would get totally > different behavior? Shouldn't the registering and parsing of this MCA param > follow our usual procedure and be done by the application itself instead of > by orterun? > > * Imagine someone has entered this MCA param into the default MCA param > file, and that it includes "foo=car" in it. Now the user sets "foo=baz" in > their environment. How many hours will the user spend tearing out his/her > hair trying to understand why the application behavior isn't as expected > before they finally realize that the default MCA param file is messing with > their non-OMPI envars? Once they finally do figure it out, how do they > "zero" that MCA param so it isn't processed? We don't have a mechanism for > overriding a value with "NULL" - doesn't this option require one? > > * again, someone puts an entry in the default MCA param file that includes > "foo=car". The user executes mpirun with "-x foo=baz", which is perfectly > legitimate. What is the precedence rule we use to determine the value of > foo? If we consolidate the two options (as you suggest), then this would be > alleviated - but one is an MCA param and the other a non-MCA cmd-line > option, so we would have to break backward compatibility to resolve it > (which isn't impossible - just worth a discussion). > > * assume an entry in the MCA param file that includes multiple envars, one > of which is "foo=car". If the user then puts "-mca env_list foo=baz" on > their cmd line, do we delete all the other envars in the original entry and > only do the new one? Or would someone expect that only the new one would be > modified or added, but the others would remain? > > Hence I think this requires some discussion at next week's call. Remember, > by policy, we don't forward non-MCA envars - but now we are forcibly setting > them only in the app procs. Strikes me as a major change in behavior, and > I'm not sure it won't cause more trouble than it solves. > > > On Apr 3, 2014, at 1:01 AM, Shamis, Pavel <sham...@ornl.gov> wrote: > >> >>> mca param file treats any key=val as mca parameter only. >>> In order to add parser support for something that is not mca param, will > require change file syntax and it will look bad, i.e.: >>> >>> mca btl = sm,self,openib >>> env DISPLAY = console:0 >>> >>> I think the current implementation is less intrusive and re-uses existing > infra in the most elegant way. >>> The param file syntax change is too big effort to justify this feature > (IMHO) which can be provided with existing infra w/o breaking anything. >> >> >> IMHO this is a useful parameter option to have. If we may consolidate >> these two parameters (-x and the new one) into single one, it might be > even more helpful. >> >> Best, >> Pasha. >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/04/14452.php > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/04/14453.php > > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4355 / Virus Database: 3722/7293 - Release Date: 04/03/14 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/04/14454.php
