Re: UDP Conduit Environment Issue

From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Sun Apr 26 2009 - 19:25:51 PDT

  • Next message: Andreev Nikita: "Unanswered questions"
      I am glad to hear that you are (mostly) pleased with the Berkeley UPC 
      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 ( and 
    enter a feature request (a bug with Severity=enhancement).
    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     

  • Next message: Andreev Nikita: "Unanswered questions"