Stefan C. Kremer
skremer at q.cis.uoguelph.ca
Thu May 22 16:39:24 EST 2003
Hi, I just finished re-reading Section 4.1 yet again (for the 12th? time). (Wow, is that ever densly packed with important info.) Each time I read it, I think I'm getting a clearer picture of what's going on. Also this list has helped me sort things out as well, but I'm still surprised at times. I'm wondering if the following synopsis makes sense. I am willing to summarize a corrected version at the end if people are interested (let me know). When I start Apapche mod_python not yet initialized. It only gets initialized when someone accesses a web-page associated with a directory directive that requires mod_python. Is that right? When mod_python is initialized it creates an interpreter called "main_interpreter". This interpreter doesn't actually run your python code it just generates sub interpreters which it keeps in a dictionay. Where is the main interpreter named "main_interpreter"? Can I access that somewhere? If apache is running as multiple processes and maybe multiple threads how many main_interpreters are there? Just one? Asside: req.interpreter doesn't work for me (under 3.0.0 (was it added in 3.0.1 or 3.0.2) or am I confused? [ File "/usr/lib/python2.2/site-packages/mod_python/apache.py", line 76, [in __getattr__ [ raise AttributeError, attr [ [AttributeError: interpreter When do the sub-interpreters get created? The sub-interpreters are, by default, associated associated with a virtual server name (but there can be more than one sub-interpreter per virtual server name). Is that right? If there are mutliple processes of apache with multiple threads, are the sub-interpreters shared betweenn processes and/or threads? When a http request comes in that uses a mod_python handler, it is assigned to a sub-interpreter. It might be assigned to a brand new sub-interpreter (usually if traffic on the server is reaching a new high level), or a previously used sub-interpreter (if traffic is less than it was at peak). (Assuming we keep hitting the same virtual server/directory/etc.) Is that right? Sub-interpreters are never destoryed, so the number of sub-interpreters increases monotonically from when apache is started until it dies and your chances of getting a used sub-interpreter goes up the longer apache has been running. Also the longer apache is running the more memory mod_python would proabely use. Is that right? If apache reduces (kills) the processes it is running, are any sub-interpreters affected? If you happen to get a re-used sub-interpreter, you will also get saddled with stuff that was defined in it before. This can be a good thing or a bad thing. If you are accessing a database, the sub-interpreter may already have an open DB connection which can save you time. It may also have already loaded some of the modules that your code calls, which can save time. Unfortunately this can be bad as well. One case occurs when you modify python code that is included as a module. If you get a sub-interpreter where the original version of the module has already been included, it will use that instead of the new one. Another example of when getting a used sub-interpreter is bad might be: User 1 writes a script that changes the sys.path variable and loads a module that they have written called MyModule. User 2 writes a script that changes the sys.path variable and loads a different module that thay have written called MyModule also! Someone requests a page from User 1 and the first version of MyModule is loaded. Then someone else requests a page from user 2, but the second version of MyModule is not loaded since the sub-interpreter thinks it has already loaded MyModule. User 2's script then goes uses the function in the wrong version of MyModule. Is this something that could happen? I'm wondering if there is an exploit that could be accomplished this way? Obviously the solution to the above problem is to use a different sub-interpreter naming scheme with "PythonInterpPerDirectory or PythonInterpPerDirective". Does that make sense? Any corrections and/or comments much appreciated. Stefan -- -- Dr. Stefan C. Kremer, Associate Prof. Reynolds Building, 106 Dept. of Computing and Information Science University of Guelph, Guelph, Ontario N1G 2W1 WWW: http://q.cis.uoguelph.ca/~skremer Tel: (519)824-4120 Ext.58913 Fax: (519)837-0323 E-mail: skremer at uoguelph.ca
|