According to Nick Johnson (a former App Engine team member) os.environ is threadsafe:
But what if my app makes use of 'os.environ' or other CGI-isms, you ask? All is not lost. The smart folks on the Python 2.7 runtime team foresaw that some apps will inevitably do this, and built in a workaround for them. 'os.environ' and a few other bits and pieces are now "thread local" on the 2.7 runtime, meaning that each thread (and hence each request) see a different copy of them, containing only the data relevant to the current request. Apps that expect to get request information from os.environ can thus continue to work fine. Bear in mind that this really is a workaround, though - it's definitely cleaner to rewrite your apps to rely only on the WSGI environment, if you have the opportunity. The WSGI environment can be accessed as self.request.environ if you're using webapp. http://blog.notdot.net/2011/10/Migrating-to-Python-2-7-part-1-Threadsafe I don't know if it is documented anywhere else, I suspected it is. - Kyle On Tuesday, August 28, 2012 4:30:16 PM UTC-5, Jason Collins wrote: > > The top answer in this SO thread suggests that os.environ should be > generally avoided because it's not threadsafe in the threadsafe: truePython > 2.7 environment. > > > http://stackoverflow.com/questions/5901653/name-of-current-app-in-google-app-engine-python > > > I'm dubious because the WSGI spec explicitly uses os.environ to construct > its request objects, etc. > > Can anyone confirm/deny the safety of using os.environ in a threadsafe: > true deployment? > > Thanks, > j > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/XTiR_ZLXOSUJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
