From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Sun Apr 26 2009 - 19:25:51 PDT
Jim, I am glad to hear that you are (mostly) pleased with the Berkeley UPC project. The short answer is that UPC_ENVPREFIX should be working if you are using bupc_getenv(), but has no promise to set the variable in the "true" environment. The propagation of the environment in a UPC application does not have a well-defined guaranteed behavior. In fact, neither does MPI. So, while using mpi-conduit is working for you it is not certain to do so with a different MPI implementation. To carry that to the next step: while you may have a way to work around the lack of a working getenv() with Berkeley UPC, there is no guarantee that you'll be able to do so with another UPC compiler. So, in the long term I'd suggest that your best course of action, IMHO, is to find a way to avoid use of getenv() or bupc_getenv() on compute nodes. If I understand correctly, you are trying to set variables that control third-party libraries, so I doubt you can do much better than what you describe (manually "republishing" the environment variables you need). Having said my piece above, I acknowledge that you do have a valid concern especially given that a user may not know at compilation time which environment variables are read by third-party libraries. The main reason we don't automatically propagate all the environment variables from the execution environment to the environment of the UPC threads is that there are cases where things break if we were to propagate certain variables (and of course we can't always know what vars are bad). So, I think it would be beneficial (and safe) if UPC_ENVPREFIX or another mechanism were available to ensure some set of user-specified environment variables reached the "true" environment (not just the private one). If you feel strongly that this feature is needed for your work. I would encourage you to visit our Bugzilla (http://upc-bugs.lbl.gov) and enter a feature request (a bug with Severity=enhancement). -Paul James Dinan wrote: > Hi, > > I've run into a slight problem with how the environment is propagated > when using the UDP conduit. I'm using BUPC 2.8.0. > > My code is calling a non-upc library function which queries an > environment variable. The environment variable can be read fine in main > but not in the non-upc library I am calling. Looking through the > translated code I realized this is because the upc compiler is > substituting bupc_getenv for calls to getenv. BUPC is then reading the > correct value from its private copy of the environment. > > Unfortunately I can't do this substitution in the library code. One > workaround is to call bupc_getenv() followed by setenv in my UPC code to > manually copy the variable from one environment to the other. But this > is not ideal. > > Is there a better way to ensure that BUPC propagates values from its > environment into the main environment? I tried setting UPC_ENVPREFIX > but that didn't help. Also, I noticed this problem does not occur when > using the mpi conduit so it may be restricted to environment handling > for the udp conduit. > > I've attached a test case that exercises my problem. Here is what the > output looks like on my system: > > ---snip--- > > $ make > gcc -Wall -c -o library.o library.c > upcc -network=udp -o env-test library.o env-test.upc > > $ export MYVAR=success > > $ upcrun -n 1 ./env-test > UPCR: UPC thread 0 of 1 on bblogin (process 0 of 1, pid=23587) > Environment lookup test. Variable name is MYVAR. > main: success > env_test: (null) > > Manually propagating variable from upc main > main: success > env_test: success > > ---snip--- > > Also, a big thanks to all who have contributed to Berkeley UPC. This is > a wonderful project! > > Best wishes, > ~Jim. > -- Paul H. Hargrove PHHargrove_at_lbl_dot_gov Future Technologies Group Tel: +1-510-495-2352 HPC Research Department Fax: +1-510-486-6900 Lawrence Berkeley National Laboratory