Ask Solem <a...@celeryproject.org> added the comment: 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10037> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
