Thursday, February 15. 2007
ajp-wsgi future directions
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
Care to elaborate on "you inherit some of the more interesting problems of mod_python... namely conforming Python's process/threading model to that of the web server's."? When you say interesting problem, is that more from the point of view of being technically interesting or that you see an actual problem that can't easily be solved without being limiting in some way?
Also don't understand the comment "I guess if you were clever, you could run the Python interpreter in only a single process, similar to how CGI works in modern versions of Apache HTTPD.". This isn't how CGI works. Apache still starts up a new process for each CGI script the last time I looked.
FWIW, mod_wsgi already exists (although not yet publically released) and runs in either prefork (multi-process) or worker (multi-process & multi-threaded) MPM modes of Apache. It is true that in part all it gives you is process management for free, since Apache does that, but mod_wsgi also provides the opportunity to avoid some of the inefficient code that exists in mod_python and correct some of its deficiencies. Because mod_wsgi targets a specific task, configuration can be made simpler and more tailored for that specific task as well.
Also don't understand the comment "I guess if you were clever, you could run the Python interpreter in only a single process, similar to how CGI works in modern versions of Apache HTTPD.". This isn't how CGI works. Apache still starts up a new process for each CGI script the last time I looked.
FWIW, mod_wsgi already exists (although not yet publically released) and runs in either prefork (multi-process) or worker (multi-process & multi-threaded) MPM modes of Apache. It is true that in part all it gives you is process management for free, since Apache does that, but mod_wsgi also provides the opportunity to avoid some of the inefficient code that exists in mod_python and correct some of its deficiencies. Because mod_wsgi targets a specific task, configuration can be made simpler and more tailored for that specific task as well.
As to "conforming Python's process/threading model to that of the web server's"... If we take Apache HTTPD as an example, if you use the prefork MPM, the embedded Python interpreter (and hence the WSGI server built on top of it) is forced to become multi-process. If you use the worker MPM, while you have multithreading, Python is still being run in multiple processes. There's no trivial pure-threaded solution. Any WSGI application you run on top of this system will be have to multi-process capable. Sure, a multithreaded application has the GIL to contend with, but a multi-process application will have to deal with data-sharing and locking across processes.
As to "similar to how CGI works in modern versions of Apache HTTPD": specifically, I'm talking about mod_cgid which forks a single daemon process which in turn is responsible alone for forking CGI scripts. It communicates with the other httpd processes via a UNIX domain socket. This relieves the httpd processes from performing the fork themselves, which may be very costly when using the worker MPM.
I'm saying this model might be used by a mod_wsgi interested in pure-threading: fork a single daemon process and run the Python interpreter solely in that process. Communicate with the other httpd processes via a UNIX domain socket...
Anyhow, embedding Python within the web server has some other issues which I didn't name specifically but were lumped under the "more interesting problems of mod_python." 1) You have multiple applications (possibly from different users) running on the same Python interpreter. This might actually be an advantage, as long as all your applications can coexist. More importantly, 2) all WSGI applications run as the web server user. It would have the same security issues as allowing non-suEXEC CGI in a shared-hosting environment.
But really, mod_python, mod_wsgi (and mod_anyinterpreter) probably aren't targeted at multi-user/shared-hosting environments.
As to "similar to how CGI works in modern versions of Apache HTTPD": specifically, I'm talking about mod_cgid which forks a single daemon process which in turn is responsible alone for forking CGI scripts. It communicates with the other httpd processes via a UNIX domain socket. This relieves the httpd processes from performing the fork themselves, which may be very costly when using the worker MPM.
I'm saying this model might be used by a mod_wsgi interested in pure-threading: fork a single daemon process and run the Python interpreter solely in that process. Communicate with the other httpd processes via a UNIX domain socket...
Anyhow, embedding Python within the web server has some other issues which I didn't name specifically but were lumped under the "more interesting problems of mod_python." 1) You have multiple applications (possibly from different users) running on the same Python interpreter. This might actually be an advantage, as long as all your applications can coexist. More importantly, 2) all WSGI applications run as the web server user. It would have the same security issues as allowing non-suEXEC CGI in a shared-hosting environment.
But really, mod_python, mod_wsgi (and mod_anyinterpreter) probably aren't targeted at multi-user/shared-hosting environments.
A single-process Python interpreter is what I'm looking for my web application, as I'm currently fighting with SQLAlchemy's caching of database data and Apache2's mod_prefork, i.e. multi-process Python interpreters without data sharing/locking.
Calendar
|
February '12 | |||||
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | ||||
Quicksearch
Categories
Syndicate This Blog
Blog Administration
Powered by
