> 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 same. > 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 explicitly. 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4