That said, being too low-level is not a Good Thing for many languages, such as Python.

Decorators are, in our humble opinion, one of the more kick-ass features of Python, so in the uWSGI source tree you will find a module exporting a bunch of decorators that cover a good part of the uWSGI API.

Signal-based decorators execute the signal handler in the first available worker.
If you have enabled the spooler you can execute the signal handlers in it, leaving workers free to manage normal requests. Simply pass target='spooler' to the decorator.

[uwsgi]; a couple of placeholderdjango_projects_dir=/var/www/appsmy_project=foobar; chdir to app project dir and set pythonpathchdir=%(django_projects_dir)/%(my_project)pythonpath=%(django_projects_dir); load djangomodule=django.core.handlers:WSGIHandler()env=DJANGO_SETTINGS_MODULE=%(my_project).settings; enable mastermaster=true; 4 processes should be enoughprocesses=4; enable the spooler (the mytasks dir must exist!)spooler=%(chdir)/mytasks; load the task.py moduleimport=task; bind on a tcp socketsocket=127.0.0.1:3031

The only especially relevant option is the import one. It works in the same way as module but skips the WSGI callable search.
You can use it to preload modules before the loading of WSGI apps. You can specify an unlimited number of ‘’‘import’‘’ directives.

uWSGI is a preforking (or “fork-abusing”) server, so you might need to execute a fixup task after each fork(). The postfork decorator is just the ticket.
You can declare multiple postfork tasks. Each decorated function will be executed in sequence after each fork().

This decorator will execute a function in fully locked environment, making it impossible for other workers or threads (or the master, if you’re foolish or brave enough) to run it simultaneously.
Obviously this may be combined with @postfork.

Offload the execution of the function to a mule <http://uwsgi-docs.readthedocs.org/en/latest/Mules.html>. When the offloaded function is called, it will return immediately and execution is delegated to a mule.

Starting from uWSGI 1.3-dev, a customizable secondary harakiri subsystem has been added. You can use this decorator to kill a worker if the given call is taking too long.

@harakiri(10)defslow_function(foo,bar):foriinrange(0,10000):foryinrange(0,10000):pass# or the alternative lower level apiuwsgi.set_user_harakiri(30)# you have 30 seconds. fight!slow_func()uwsgi.set_user_harakiri(0)# clear the timer, all is well