Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

system/qx in thread uses wrong %ENV #8736

Open
p5pRT opened this issue Jan 10, 2007 · 7 comments
Open

system/qx in thread uses wrong %ENV #8736

p5pRT opened this issue Jan 10, 2007 · 7 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 10, 2007

Migrated from rt.perl.org#41222 (status was 'open')

Searchable as RT41222$

@p5pRT
Copy link
Author

p5pRT commented Jan 10, 2007

From @jdhedden

Created by @jdhedden

If a thread makes changes to %ENV and then uses 'qx/system',
the changes to the environment variables are not available
to the command run by 'qx/system'. Instead it sees %ENV
(and any changes made to it) from the 'main' thread.

In other words, when run in a thread 'qx/system' does not
use %ENV for that thread, but rather %ENV from the main
thread.

The following code illustrates this​:

  #!/usr/bin/perl

  use strict;
  use warnings;
  $| = 1;

  use threads;

  $ENV{'MAIN'} = 'ENV{MAIN} set in main thread';
  system('echo MAIN​: $MAIN');
  system('echo MAIN​: $THRD --- this should be blank');
  print("\n");

  threads->create(sub {
  system('echo THRD​: $MAIN');

  $ENV{'THRD'} = 'ENV{THRD} set in child thread';
  system('echo THRD​: $THRD -- this should NOT be blank');
  })->join();

  print("\n");
  system('echo MAIN​: $MAIN');
  system('echo MAIN​: $THRD --- this should be blank');

  # EOF

The above produces the following output​:

  MAIN​: ENV{MAIN} set in main thread
  MAIN​: --- this should be blank

  THRD​: ENV{MAIN} set in main thread
  THRD​: -- this should NOT be blank

  MAIN​: ENV{MAIN} set in main thread
  MAIN​: --- this should be blank

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.8.8:

Configured by Jerry at Wed Jan 10 07:54:30 EST 2007.

Summary of my perl5 (revision 5 version 8 subversion 8) configuration:
  Platform:
    osname=cygwin, osvers=1.5.23(0.15642),
archname=cygwin-thread-multi-64int
    uname='cygwin_nt-5.0 pn100-02-2-054p 1.5.23(0.15642) 2006-12-19
10:52 i686 cygwin '
    config_args='-de -Duse64bitint -Dusethreads -Uusemymalloc
-Dnoextensions=attrs IPC/SysV -A define:optimize=-O3 -pipe
-funit-at-a-time -mtune=pentium4m -march=pentium4 -mfpmath=sse
-mieee-fp -mmmx -msse -msse2 -A define:ld=/usr/bin/ld2 -A
append:ccflags= -DPERL_DONT_CREATE_GVSV -DNO_MATHOMS'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -DPERL_DONT_CREATE_GVSV
-DNO_MATHOMS -fno-strict-aliasing -pipe -Wdeclaration-after-statement',
    optimize='-O3 -pipe -funit-at-a-time -mtune=pentium4m
-march=pentium4 -mfpmath=sse -mieee-fp -mmmx -msse -msse2',
    cppflags='-DPERL_USE_SAFE_PUTENV -DPERL_DONT_CREATE_GVSV
-DNO_MATHOMS -fno-strict-aliasing -pipe -Wdeclaration-after-statement'
    ccversion='', gccversion='3.4.4 (cygming special, gdc 0.12, using
dmd 0.125)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='/usr/bin/ld2', ldflags =' -s -L/usr/local/lib'
    libpth=/usr/local/lib /usr/lib /lib
    libs=-lgdbm -ldb -ldl -lcrypt -lgdbm_compat
    perllibs=-ldl -lcrypt -lgdbm_compat
    libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
    cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'

Locally applied patches:
    MAINT28213
    29737


@INC for perl v5.8.8:
    /usr/lib/perl5/5.8/cygwin
    /usr/lib/perl5/5.8
    .


Environment for perl v5.8.8:
    CYGWIN=server ntsec
    HOME=/home/jhedden
    LANG=C
    LANGUAGE=C
    LC_ALL=C
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
   
PATH=/home/jhedden/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/Perl/bin:/c/djgpp/bin:/c/Program
Files/WiX:/c/Program Files/nant-0.85-rc3/bin:/c/Program
Files/apache-ant-1.6.3/bin:/c/j2sdk1.4.2_08/bin:/c/Program
Files/Documentum/Shared:/c/blp/API:/c/oracle/ora92/bin:/c/Program
Files/Oracle/jre/1.3.1/bin:/c/Program
Files/Oracle/jre/1.1.8/bin:/c/WINNT/system32:/c/WINNT:/c/WINNT/system32/WBEM:/c/Program
Files/cvsnt:/c/Program Files/QuickTime/QTSystem/:/c/dev-cpp/bin/:.
    PERLIO=perlio
    PERL_BADLANG (unset)
    SHELL (unset)


 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

@p5pRT
Copy link
Author

p5pRT commented Feb 5, 2007

From @jdhedden

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=41222 >

If a thread makes changes to %ENV and then uses 'qx/system',
the changes to the environment variables are not available
to the command run by 'qx/system'. Instead it sees %ENV
(and any changes made to it) from the 'main' thread.

In other words, when run in a thread 'qx/system' does not
use %ENV for that thread, but rather %ENV from the main
thread.

Is this on anyone's TODO list? (Or did it slip through the cracks?)

____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http​://videogames.yahoo.com/platform?platform=120121

@p5pRT
Copy link
Author

p5pRT commented Feb 5, 2007

From @jandubois

On Mon, 5 Feb 2007 14​:08​:12 -0800 (PST), "Jerry D. Hedden"
<jdhedden@​yahoo.com> wrote​:

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=41222 >

If a thread makes changes to %ENV and then uses 'qx/system',
the changes to the environment variables are not available
to the command run by 'qx/system'. Instead it sees %ENV
(and any changes made to it) from the 'main' thread.

In other words, when run in a thread 'qx/system' does not
use %ENV for that thread, but rather %ENV from the main
thread.

Is this on anyone's TODO list? (Or did it slip through the cracks?)

This should not be happening on Windows. The code in win32_spawnvp()
uses the perlhost container to create an interpreter specific
environment and current working directory.

I'm not sure if you want to tackle just the environment variable issue
on Unix, or deal with e.g. the current directory too? Eventually you'll
re-invent a mechanism like win32/perlhost.h to virtualize all OS
interaction though another level of indirection. :)

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Feb 5, 2007

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Feb 5, 2007

From @jdhedden

Jerry D. Hedden wrote​:

# <URL​: http​://rt.perl.org/rt3/Ticket/Display.html?id=41222 >

If a thread makes changes to %ENV and then uses 'qx/system',
the changes to the environment variables are not available
to the command run by 'qx/system'. Instead it sees %ENV
(and any changes made to it) from the 'main' thread.

In other words, when run in a thread 'qx/system' does not
use %ENV for that thread, but rather %ENV from the main
thread.

Is this on anyone's TODO list? (Or did it slip through the
cracks?)

Jan Dubois wrote​:

This should not be happening on Windows. The code in
win32_spawnvp() uses the perlhost container to create an
interpreter specific environment and current working
directory.

Okay. I didn't test it on Win32, just Cygwin. (I presume it
works the same under Unix, Linux, etc., but I could be
wrong.)

I'm not sure if you want to tackle just the environment
variable issue on Unix, or deal with e.g. the current
directory too? Eventually you'll re-invent a mechanism
like win32/perlhost.h to virtualize all OS interaction
though another level of indirection. :)

I hope you're speaking to others on the list when you say
'you' as I have no idea how to address this.

____________________________________________________________________________________
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
http​://videogames.yahoo.com/platform?platform=120121

@p5pRT
Copy link
Author

p5pRT commented Feb 5, 2007

From @jandubois

On Mon, 5 Feb 2007 14​:43​:05 -0800 (PST), "Jerry D. Hedden"
<jdhedden@​yahoo.com> wrote​:

I'm not sure if you want to tackle just the environment
variable issue on Unix, or deal with e.g. the current
directory too? Eventually you'll re-invent a mechanism
like win32/perlhost.h to virtualize all OS interaction
though another level of indirection. :)

I hope you're speaking to others on the list when you say
'you' as I have no idea how to address this.

Sorry, I did not want to discourage you from attacking the %ENV problem;
I just wanted to point out that there are other OS resources that aren't
properly virtualized between threads either. And also that there is one
particular implementation already in the core that deals with this on
one platform only.

Personally, I won't be able to do any work on this particular issue.
I'm also not necessarily recommending that win32/perlhost.h is the right
way to deal with it (it has lots of historical baggage from the OnePerl
effort), and extending it to all platforms seems like overkill. It was
implemented for Windows because under the fork() emulation different
threads pretend to *be* different processes.

It may be worthwhile to fix the %ENV issue and leave the working
directory alone, even though it would be nice to get this working for
mod_perl...

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Apr 17, 2007

From guest@guest.guest.xxxxxxxx

Dear folks,

I hadn't kept track of this, and a colleaguejust brought this forum
thread to light. I was the originator of the problem that raised the bug
report. If you look on the CPAN forum
http​://www.cpanforum.com/posts/4002 you'll see it there.

The problem originated from code I was writing for Linux and AIX. So,
not just (or in my case - even) Cygwin, no.

Just wanted to add that thought.

Kind regards

Derek Jones (scunacc@​yahoo.com)

On Mon Feb 05 15​:07​:18 2007, jdb wrote​:

On Mon, 5 Feb 2007 14​:43​:05 -0800 (PST), "Jerry D. Hedden"
<jdhedden@​yahoo.com> wrote​:

I'm not sure if you want to tackle just the environment
variable issue on Unix, or deal with e.g. the current
directory too? Eventually you'll re-invent a mechanism
like win32/perlhost.h to virtualize all OS interaction
though another level of indirection. :)

I hope you're speaking to others on the list when you say
'you' as I have no idea how to address this.

Sorry, I did not want to discourage you from attacking the %ENV problem;
I just wanted to point out that there are other OS resources that aren't
properly virtualized between threads either. And also that there is one
particular implementation already in the core that deals with this on
one platform only.

Personally, I won't be able to do any work on this particular issue.
I'm also not necessarily recommending that win32/perlhost.h is the right
way to deal with it (it has lots of historical baggage from the OnePerl
effort), and extending it to all platforms seems like overkill. It was
implemented for Windows because under the fork() emulation different
threads pretend to *be* different processes.

It may be worthwhile to fix the %ENV issue and leave the working
directory alone, even though it would be nice to get this working for
mod_perl...

Cheers,
-Jan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants