[Web-SIG] Web Site Process Bus

[Alan Kennedy]

[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.