[Web-SIG] Web Site Process Bus

[Graham Dumpleton]

On 26/06/07, Joseph Tate <jtate at rpath.com> wrote:
> 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
> natural division.
>
> <snip lots of interesting things about SystemExit>
> A web bus obviates the need to signal other processes in the process group.

It depends.

> I'm not clear on how the web bus devolves in the multi-process state though.

I guess with mod_wsgi I have the worst case scenario as I have to deal
with not only multiple processes, but also the possible presence of
multiple sub interpreters within a process and many distinct WSGI
applications being run in parallel.

Consider a few use case examples. First one is where Apache is being
shutdown or restarted. To tell the child process to shutdown, the main
process will send as many characters onto the pipe of death as there
are child processes. Each child process reads one character when it
sees data is available on the pipe of death and then shuts down the
process.

As part of the child process shutdown it will trigger destruction of
the child memory pool. To this would be registered cleanup callbacks,
one of which is a callback into mod_wsgi. From that callback all the
sub interpreters which have been created will in turn have any threads
cleaned up and then exit funcs called.

Within this bus scheme, prior to any threads being cleaned up,
mod_wsgi would need to signal any subscribed parties in the sub
interpreter that the the process (server) is being shutdown.

Now having a bus only know about stuff local to the process in this
case is fine as the propagation of the event comes from outside and
ends up inside. The problem is cases where it may be valid that the
source of the signal is actually inside of the WSGI application.

The issue here is one of scope and how does one know how far the event
should propagate. In mod_wsgi you have the decision as to whether the
event should only be propagated within the same sub interpreter,
whether it makes sense to propagate it to other sub interpreters
within the same process, or finally whether other process also need to
be notified. When it hits the other processes, does it go to all sub
interpreters, or just the interpreter with the same name as the
originating application in the other process, ie., where another copy
of the same application would be running.

In practice I think the bus has to be restricted so as to be as simple
as possible and for external packages to be used if more sophisticated
signalling between multiprocess applications is required. But then in
saying that, making it simple and keeping it just to that sub
interpreter or process may actually prevent some of the things being
discussed being feasible, at least in the context of Apache.

The only way we may know is to start stepping through specific uses
cases one at a time, not even worrying about the mechanisms of how the
bus may actually work, and discuss what would the intention of each
be.

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

In Apache changing the certificates would need a complete restart of
everything. Because the  child processes aren't privileged they would
not be able to trigger the main server to do so. This actually gets to
one of my reservations about some of the stuff being discussed. That
is, that the WSGI applications should even have any ability to control
the underlying web server. In a shared web hosting environment using
Apache, allowing such control is not practical as you don't want
arbitrary user doing things to the server. If you are running Apache
as a dedicated server for a single application that is a different
matter however. Thus some aspects of what can be done by via the bus
would  have to be controllable dependent on the environment in which
one is running.

At least with Apache, even initiating this sort of stuff from inside
of a WSGI application may not make a great deal of sense even then. It
would be far easier and preferable in Apache to use a suexec CGI
script to accept the upload of the SSL certificate and then trigger a
restart of Apache. So in the end the bus concept may be great for pure
Python system, but not so sure about a complicated mixed code system
like Apache, especially where there may be better ways of handling it
through other features of Apache.

Graham