The state of gevent-spawn
ludvig.ericson
the past written partway of a WSGI HTTP server based on gevent. You
can find it at http://bitbucket.org/lericson/gevent-spawn/
I thought I'd sum up my goals for the project, as well as what has
been done, so there's some official record thereof.
The primary goal is to do right what the competition does wrong, the
competition being mainly eventlet's Spawning. Spawning is great and
all, and I use with a host of clients to deploy WSGI applications in
high-performance environments.
However, it does have some (very) rough edges, like an inability to
turn off code reloading, and a sort of weird internal architecture,
making it hard to work on.
Some of the goals I have for gevent-spawn is:
- easy, rememberable command-line interface -- should be usable as a
development tool,
- multitasking through coroutines and process forks -- no threading
whatsoever,
- proper daemonization support so rc-scripts work reliably,
- proper process names, so one can see what is what in a `ps aux`,
- proper handling of child death, no stale zombie processes hanging
about,
- proper support for logging, not interfering with the application's
configuration
So far, the command-line interface is in a draft state but is getting
there. The core philosophy here is DWIM (Do What I Mean), rather than
the oh too common let-me-specify-each-and-every-aspect-of-every-
conceivable-part-of-the-program.
The multitasking is implemented by means of forking worker processes,
and having a master watch over these. This works very well, I think.
Daemonization works pretty well through the python-daemon project, and
writes PID-files and all that essential stuff (chroot, setuid/setgid,
etc.)
Process names have been added recently, through the setproctitle
library, and is of course optional (but a very, very nice thing to
have in a large installation)
Handling of child death is implemented through the use of the SIGCHLD
signal, and as such it shouldn't be possible to lose a child without
noticing unless the machine's kernel or otherwise has a bug.
Logging, however, is where the rough edges are right now. The sort of
ugly solution in place is to use a log_server method which always
writes to stderr, which is suboptimal -- if the WSGI application
errors out, it'll be using stderr, and hence you want stderr to go to
some place where the administrator keeps an eye. Writing status
information there might not be desirable.
Furthermore in the logging aspect is the potential use of the logging
package in the standard library. While it'd be neat and all, my
experience is that if gevent-spawn were to use it, configuration of
the logging would interfere with the potential use of the logging
package within the WSGI application hosted. Not sure how Google App
Engine handles this, but never had an issue there. Also werkzeug's
runserver does it nicely.