[Graham Dumpleton] > First comment is about WSGI applications somehow themselves using > SIGTERM etc as triggers for things they want to do. For Apache at > least, allowing any part of a hosted Python application to register > its own signal handlers is a big no no. This is because Apache itself > uses a whole range of signals to manage such tasks as shutting down > sub processes or signaling worker and/or listener threads within a > process that its time to wakeup or shutdown. If a WSGI application > starts registering signal handlers it can as a result stop Apache from > even being able to process requests. In mod_wsgi I have had to > specifically take steps to prevent applications breaking things in > this way by replacing signal.signal() on creation of an interpreter. > Instead I log a warning that the signal registration has been ignored > and otherwise do nothing. This was simply the safest thing to do. > > Thus I believe a clear statement should be made that UNIX signals are > off limits to WSGI applications or components.
From a jython POV, I agree with this statement; signals don't even exist on java/jython (although some JVMs have non-standard extensions for signals). Thus, any "standard" involving signals would not be implementable on jython, and I guess ironpython too. [Graham Dumpleton] > Anyway, just wanted to make it absolutely clear that I don't believe a > hosted WSGI application and associated framework has any business > taking direct interest in low level UNIX signals. Agreed. Regards, Alan. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
