homepage

Later works, or just close it. I can open up a new issue to merge the improvements in billiard later.
> The execv stuff certainly won't go in by Py3.3. There has not been 
> consensus that adding it is a good idea.
> (I also have the unit tests passing with a "fork server": the server >process is forked at the beginning of the program and then forked >children of the server process are started on request. It is about 10 >times faster then using execv, and almost as fast as simple forking.)
Ah, a working 'fork server' would be just as good.
Btw, Billiard now supports running Pool without threads, using epoll/kqueue/select instead. So Celery uses that when it can be nonblocking, and execv when it can't. It performs way better without threads, and in addition shutdown + replacing worker processes is much more responsive. Changing the default Pool is not going to happen, but ncluding a simple select() based Pool would be possible, and then it could also easily work with Twisted, Eventlet, Gevent, etc. (especially now that the Connection is rewritten in pure python).