This section describes the asynchronous WSGI specification used by pulsar. It is a superset of the WSGI 1.0.1 specification for synchronous server/middleware. If an application handler is synchronous, this specification is exactly equivalent to WSGI 1.0.1. Changes with respect WSGI 1.0.1 concern asynchronous responses and nothing else.
The WSGI interface has two sides: the
gateway side, and the
framework side. The server side invokes a callable
object, here referred as application handler, that is provided by the
A standard WSGI application handler is always a callable, either a function
or a callable object, which accepts two positional arguments:
start_response. When called by the server,
the application object must return an iterable yielding zero or more bytes.
Pulsar is shipped with two WSGI application handlers documented below.
An asynchronous iterable is an iterable over a combination of
Future which result in
For example this could be an asynchronous iterable:
def simple_async(): yield b'hello' c = Future() c.set_result(b' ') yield c yield b'World!'
The first application handler is the
which is a step above the hello callable
in the tutorial. It accepts two iterables, a list of
wsgi middleware and an optional list of
WsgiHandler(middleware=None, response_middleware=None, async=True)¶
An handler for applications conforming to python WSGI.
List of asynchronous WSGI middleware callables which accept
start_responseas arguments. The order matter, since the response returned by the callable is the non
Nonevalue returned by a middleware.
Lazy Wsgi Handler¶
A wsgi handler which loads the actual handler the first time it is called.
Subclasses must implement the
setup()method. Useful when working in multiprocessing mode when the application handler must be a
picklableinstance. This handler can rebuild its wsgi
handlerevery time is pickled and un-pickled without causing serialisation issues.
Pulsar injects two server-defined variables into the WSGI environ:
Connectionserving the request
Configdictionary of the server
The event loop serving the application can be retrieved from the connection
loop = environ['pulsar.connection']._loop