[Twisted-Python] INCOMPATIBLE CHANGE: twisted.python.threadpool

weykent weykent at weasyl.com
Fri Sep 26 02:12:53 MDT 2014


On Sep 26, 2014, at 12:43 AM, Glyph <glyph at twistedmatrix.com> wrote:

> How about this: would you mind if ThreadPool were modified to still populate these attributes for monitoring and debugging purposes, but completely stopped honoring any destructive operations on them?  In the case of "pool.q", there is no single Queue responsible for the whole pool, so I would like to make "put", "get", and "join" actually raise exceptions; in the case of "waiters" and "working" I guess I could fish out some actual Thread objects, that just involves a little bit of sad abstraction violation internal to the twisted.threads.Team implementation.

Having objects with only nondestructive methods would be fine for me. I don’t even care about getting Thread objects out, and I certainly hope nobody else cares about getting Thread objects out either.

> My inclination would be to expand the thread pool to accommodate these usages, but still deprecate these attributes in the next version; but add a better "statistics" method that returned an object with "active", "pending", and "idle" attributes (all integers).

This sounds fantastic. I’ll graph whatever the statistics method emits, so feel free to include other useful or interesting metrics as well. (Though, I’m not sure what else there is that’s easy to keep track of and useful.)

> So would that work for you?

Yes, absolutely. 

> Touching private (underscore-prefixed) implementation details is explicitly not supported - if you did it that way, you're on your own :-).  And, as the end-user in this discussion, you win the argument by default.  (You can see how I feel about supporting users here: <https://twitter.com/mjg59/status/514670470260465664>)  Plus, if we're going to work on the thread-pool and have newer, better interfaces, WSGIResource's implementation is likely to change.

I haven’t touched private implementation details of WSGIResource, nor was I planning to. I’ve already had some code (in another project) break across versions of twisted because of that, and I don’t want it to happen again.

> Thanks a bunch for helping us improve Twisted,

Thank you for taking the time to write up your original post and this reply!
~weykent





More information about the Twisted-Python mailing list