Selwin Ong

> The first, is that this is not obvious: is a thread a horse? How about a worker that runs each job on a separate process (using multiprocess for example)?...

> Not sure I follow, what I mean was that if horse-related methods are not used by everyone, would make more sense to have the "base" worker (the one everyone...

> You mean the __check_pending_dependents? Sure let's look at this logic, that was a solution I found since multiple tests were failing - since the work was not sequential anymore,...

I took a more thorough look on the implementation so far. My feedbacks: 1. `worker._current_jobs` is implemented nicely, we should bring this into RQ and should be made into public...

> Most definitely yes, my point here is that we could implement the protocol step by step, mainly because we are going to learn other things when implementing new workers....

As an aside, if we can land this PR, [ProcessPoolExecutor](https://docs.python.org/3/library/concurrent.futures.html#processpoolexecutor) has very similar APIs so we'll actually get `Process` based concurrency in addition to `Thread` based one 😀.

Just so that we don't work on the same things, I'm working on bringing `worker._current_jobs` to `Worker` class.

> Just so that we don't work on the same things, I'm working on bringing worker._current_jobs to Worker class. Unless you're already working on this, let me know. I'll work...

Mind making a PR to fix this?

@yyaadet I cherry-picked your commit that shows `job.ended_at` in this https://github.com/rq/django-rq/pull/557 . I'm not sure about iterating through all jobs in `FinishedJobRegistry` and averaging it on the fly. If we...