As I said in the original issue, I think this should be a single stats() method that returns a dictionary. There are two reasons:

• With several methods, there's a race condition: if I call waiting_task_count() then active_task_count(), I'm not sure the two numbers are comparable since they reflect snapshots at different points in time; a single method can guarantee the snapshot is consistent (perhaps it needs to take a lock for that, that's an implementation issue)
• It makes the API simpler: we can add a lot of content to the stats dictionary without clobbering the API and the API docs :-)

Of course, the returned dictionary would be something like:

{'worker_count': 8,
 'active_worker_count': 3,
 'idle_worker_count': 5,
 # etc.
}

I'd also see something like a "status" field reflecting the state of the executor ("running", "shutting_down", "shutdown", "broken" perhaps).

By the way, you should probably base your work on PR #4241 because I'm soon gonna merge it :-)

I just rebased the PR and I will implement the stat API asap.

Woops... It looks like squashing PR #4241 on push left this PR with conflicts. I'm sorry :-/

@tomMoral would you like to revive this PR? Also @ogrisel

Yes I will rebase it and see what needs to be improved.

@pitrou I think this PR implements a basic API for the introspection. Now it is a matter of what should we add in it.

You mentioned the addition of a 'status' for the pool ("running", "shutting_down", "shutdown", "broken"). I don't know if you want to add more?

We could easily add timing for the different states of the futures. This would allow to gain info on the average waiting time/running time in the executor but I am not sure how interesting it is.

@tomMoral I think we don't need to add more statistics for now. OTOH the implementation is more complicated than I expected. Is _ExecutorFlags really needed or useful? I'm not sure we should add too much complexity for a little-used feature.

@pitrou My first take was to implement the 'status' without it and I got some failure due to concurrency issues (if I remember correctly). The _ExecutorFags mechanism is probably not needed in itself but IMO, it simplifies the management of the flags and it makes is more robust for future changes as all the flags can be managed in a conscistent way. But if you think it is unnecessary, I will try a simpler implementation. Let me know what you think is best.

And sorry for the long delay, I just got back from vacations.

Is there still interest in this change? It looks like there have been other changes merged since this was created. Thanks!

This PR is stale because it has been open for 30 days with no activity.

The following commit authors need to sign the Contributor License Agreement:

• toma.moral@gmail.com

This PR is stale because it has been open for 30 days with no activity.