[Python-Dev] Re: [PyWX] RE: PyWX (Python AOLserver plugin)
Guido van Rossum
Tue, 12 Sep 2000 18:07:40 -0500
> 3. We address sys.argv (is this just a bug on our part maybe?)
Probably. The variables are not shared -- thir initial values are the
> 4. Can we address the os.environ leak similarly? I'm trying to
> think of cases where a CGI really should be allowed to add to
> the environment. Maybe someone needs to set an environment variable
> used by some other program that will be run in a subshell. If
> so, maybe we can somehow serialize activities that modify os.environ
> in this way?
You each get a copy of os.environ.
Running things in subshells from threads is asking for trouble!
But if you have to, you can write your own os.system() substitute that
uses os.execve() -- this allows you to pass in the environment
You may have to take out (override) the code that automatically calls
os.putenv() when an assignment into os.environment is made.
> Idea: If Python forks a subshell, it inherits the parent
> process's environment. That's probably the only time we really want
> to let someone modify the os.environ -- so it can be passed to
> a child. What if we serialized through the fork somehow like so:
> 1. Python script wants to set environment, makes call to os.environ
> 1a. We serialize here, so now we are single-threaded
> 2. Script forks a subshell.
> 2b. We remove the entry we just added and release mutex.
> 3. Execution continues.
> This probably still won't work because the script might now expect
> these variables to be in the environment dictionary.
> Perhaps we can dummy up a fake os.environ dictionary per interpreter
> thread that doesn't actually change the true UNIX environment?
See above. You can do it!
--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)