Since discussion is moving towards look at defining responsibilities of the container or environment that a WSGI application runs in, thought it would be a good time to ask this question.
The question is, if a WSGI application calls sys.exit() or raises a SystemExit exception explicitly, what action if any should a WSGI server/adapter take in response. Should it allow the process to be shutdown, or should it ignore it. If the WSGI server/adapter doesn't ignore it, then you run the risk of a WSGI application shutting down your whole web server if everything runs within the one process. In the case of a web server where applications run in multiple spawned child process, eg Apache, then you only affect the one process that the request was handled within. Even so, in the case of Apache, if the worker MPM was being used and thus there could be requests being handled in parallel in the same process, maybe not even as Python requests, but static file requests, PHP requests, CGI etc, then these other requests would still be affected by the process being killed. Thus to my mind any WSGI server/adapter should possibly always ignore a SystemExit exception coming from with an executing WSGI application. One though also has to worry about SystemExit exceptions raised as a side effect of a Python import performed to load a WSGI application. Then you potentially have the issue of SystemExit exception raised from thread spawned by WSGI application. What are other peoples thoughts on this. Should one try and protect the container application from abuse of SystemExit by a WSGI application or should one simply trust the application writer? In a shared web hosting environment can someone ever trust an application writer in this way though? Comments? Graham _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
