[Web-SIG] Web Site Process Bus
jtate at rpath.com
Tue Jun 26 06:06:34 CEST 2007
On Monday 25 June 2007 22:48:47 Graham Dumpleton wrote:
> Thus I believe a clear statement should be made that UNIX signals are
> off limits to WSGI applications or components. I have no problem with
> the underlying server upon which the WSGI adapter sits using them for
> its own purposes, however, knowledge of signals should stay in that
> layer. Now it may be the case that a higher level application signal
> may be generated as a result of a SIGTERM in a specific server
> implementation, for example shutdown, but the name or type of signal
> does have to be distinct, ie., "shutdown" and have no linkage to the
> UNIX signal.
I think this is fine. Signal handlers only get run in the main thread anyway,
so ignoring them for sub-threads (like handlers, dispatchers, etc) is a
<snip lots of interesting things about SystemExit>
A web bus obviates the need to signal other processes in the process group.
I'm not clear on how the web bus devolves in the multi-process state though.
My particular use case for keeping SystemExit around is I have an app that
allows the user to upload a new SSL certificate. Without a restart, or
perhaps, given a WSPBus, just a drop to IDLE state, the new SSL certificate
would not be applied to new incoming connections. The thread that puts the
new SSL Certificate in place needs to be able to tell the entire server to
A second use case has already been mentioned: reloading running code. The
same app as above runs the system software update mechanism. When that
update completes (which could contain a new core c library, new python, new
modules, new application code, or even new configuration data) the server
needs to reload.
I think that SystemExit should not be removed from the WSGI application layer,
unless it's replaced with another mechanism that allows the working
thread/process to signal that the entire server should be restarted/reloaded.
(919) 851-3984 x2106
More information about the Web-SIG