Vincent Driessen

Oh yes, this will be pulled into the main repo—definitely! I still need to take a look at it, though, but I've been too busy lately.

Nothing planned. If I don't see any problems with it for future development and it works reliably, I pull. As said, I simply haven't had the time to play with...

I acknowledge that @jgelens' work on the gevent workers is really interesting, and I would love to have it available in RQ. However, I'm still a bit hesitant to pull,...

Thanks for your thoughts, @selwin! Currently, the worker is responsible for dequeueing and unpickling the job function and the horse is responsible for execution (in an isolated context). The `GeventWorker`...

Oh, wait a minute. I suddenly remember something. When I first wrote the worker implementation, I did consider supporting a pool for multiple members. This is what was so nasty...

@selwin, I agree that dequeueing jobs from within the horse makes the problem much simpler. So it might not be as bad an idea as I originally thought. `gevent` provides...

OK. This is what I'm thinking about currently: The main worker loop could be reduced to this: ``` def work(self): """Forever, keep spawning children (this is like how a "pre-fork"...

I'm going to be looking at this really soon! (Fixing some production issues now, first.)

I don't understand the problem in the first place. Stripping away django-rq and RQ from the equation, what's the core of the problem we're looking at here? Isn't it that...

> You could certainly argue the same thing about Queue being a central component that routes jobs to workers. Actually, queues are used in RQ for more than just enqueueing...