On 15 September 2011 12:17, Brad Mclain <[email protected]> wrote: > Hi, > Just looking for some best practice advice for using mpm-worker mod_wsgi > with shared objects. > Two examples of this include access to the jinja2 template environment and a > SQLAlchemy session spawner for database queries. We would like to be able to > easily access these from different parts of the application but > are concerned about thread safety. > Is it safe to set these up as a global values in a package so it can be > imported to any script? > Does any of this change with regards to Embedded or Daemon mode? > I guess the other thing to consider is that this may depend on the thread > safety of the third party libraries as opposed to mod_wsgi.
When Python modules are imported a global import lock is held, so you are at least are guaranteed that module only imported once and you don't need to use locking when initialising data structures at global scope in a module on import of that module. Beyond that, whether locking is needed on use of the data structure is going to depend on what it does. The WSGI import script when imported uses the same global import lock and same applies, however, the WSGI script file would not be a good place to put global data as the WSGI script file could be reloaded in same process for embedded mode, plus not easy to import WSGI script file module elsewhere into app to access them. In short, don't put shared global data in WSGI script file. Other than that, if you haven't read it already, there are a few comments about global data sharing in: http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading#Sharing_Of_Global_Data Besides that, general rules about multithread programming in Python apply. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
