An implementation of the Web Site Process Bus.
This module is completely standalone, depending only on the stdlib.
Web Site Process Bus¶
A Bus object is used to contain and manage site-wide behavior: daemonization, HTTP server start/stop, process reload, signal handling, drop privileges, PID file management, logging for all of these, and many more.
In addition, a Bus object provides a place for each web framework to register code that runs in response to site-wide events (like process start and stop), or which controls or otherwise interacts with the site-wide components mentioned above. For example, a framework which uses file-based templates would add known template filenames to an autoreload component.
Ideally, a Bus object will be flexible enough to be useful in a variety of invocation scenarios:
The deployer starts a site from the command line via a framework-neutral deployment script; applications from multiple frameworks are mixed in a single site. Command-line arguments and configuration files are used to define site-wide components such as the HTTP server, WSGI component graph, autoreload behavior, signal handling, etc.
The deployer starts a site via some other process, such as Apache; applications from multiple frameworks are mixed in a single site. Autoreload and signal handling (from Python at least) are disabled.
The deployer starts a site via a framework-specific mechanism; for example, when running tests, exploring tutorials, or deploying single applications from a single framework. The framework controls which site-wide components are enabled as it sees fit.
The Bus object in this package uses topic-based publish-subscribe messaging to accomplish all this. A few topic channels are built in (‘start’, ‘stop’, ‘exit’, ‘graceful’, ‘log’, and ‘main’). Frameworks and site containers are free to define their own. If a message is sent to a channel that has not been defined or has no listeners, there is no effect.
In general, there should only ever be a single Bus object per process. Frameworks and site containers share a single Bus object by publishing messages and subscribing listeners.
The Bus object works as a finite state machine which models the current state of the process. Bus methods move it from one state to another; those methods then publish to subscribed listeners on the channel for the new state.:
O | V STOPPING --> STOPPED --> EXITING -> X A A | | \___ | | \ | | V V STARTED <-- STARTING
Process state-machine and messenger for HTTP site deployment.
All listeners for a given channel are guaranteed to be called even if others at the same channel fail. Each failure is logged, but execution proceeds on to the next listener. The only way to stop all processing from inside a listener is to raise SystemExit and stop the whole server.
Assert that the Bus is not running in atexit handler callback.
Re-execute the current process.
This must be called from the main thread, because certain platforms (OS X) don’t allow execv to be called in a child thread very well.
Prepend current working dir to PATH environment variable if needed.
If sys.path is an empty string, the interpreter was likely invoked with -m and the effective path is about to change on re-exec. Add the current directory to $PYTHONPATH to ensure that the new process sees the same path.
This issue cannot be addressed in the general case because Python cannot reliably reconstruct the original command line (http://bugs.python.org/issue14208).
(This idea filched from tornado.autoreload)
Retrieve current Python interpreter’s arguments.
Returns empty tuple in case of frozen mode, uses built-in arguments reproduction function otherwise.
Frozen mode is possible for the app has been packaged into a binary executable using py2exe. In this case the interpreter’s arguments are already built-in into that executable.
Retrieve all real arguments of the python interpreter.
…even those not listed in
Set the CLOEXEC flag on all open files (except stdin/out/err).
If self.max_cloexec_files is an integer (the default), then on platforms which support it, it represents the max open files setting for the operating system. This function will be called just before the process is restarted via os.execv() to prevent open files from persisting into the new process.
Set self.max_cloexec_files to 0 to disable this behavior.
Wait for the EXITING state, KeyboardInterrupt or SystemExit.
This function is intended to be called only by the main thread. After waiting for the EXITING state, it also waits for all threads to terminate, and then calls os.execv if self.execv is True. This design allows another thread to call bus.restart, yet have the main thread perform the actual execv call (required on some platforms).
Stop all services and prepare to exit the process.
Advise all services to reload.
log(msg='', level=20, traceback=False)¶
Log the given message. Append the last traceback if requested.
publish(channel, *args, **kwargs)¶
Return output of all subscribers for the given channel.
Restart the process (may close connections).
This method does not restart the process from the calling thread; instead, it stops the bus and asks the main thread to call execv.
Start all services.
start_with_callback(func, args=None, kwargs=None)¶
Start ‘func’ in a new thread T, then start self (and return T).
states= <cherrypy.process.wspbus._StateEnum object>¶
Stop all services.
subscribe(channel, callback=None, priority=None)¶
Add the given callback at the given channel (if not present).
If callback is None, return a partial suitable for decorating the callback.
Discard the given callback (if present).
wait(state, interval=0.1, channel=None)¶
Poll for the given state(s) at intervals; publish to channel.
Exception raised during errors on Bus.publish().
Return a list of seen exception instances.
Append the current exception to self.