twisted._threads : API documentation

Module	_convenience	Common functionality used within the implementation of various workers.
Module	_ithreads	Interfaces related to threads.
Module	_memory	Implementation of an in-memory worker that defers execution.
Module	_pool	Top level thread pool interface, used to implement `twisted.python.threadpool`.
Module	_team	Implementation of a `Team` of workers; a thread-pool that can allocate work to workers.
Module	_threadworker	Implementation of an `IWorker` based on native threads and queues.

From the __init__.py module:

Class	AlreadyQuit	This worker worker is dead and cannot execute more instructions.
Interface	IWorker	A worker that can perform some work concurrently.
Class	LockWorker	An `IWorker` implemented based on a mutual-exclusion lock.
Class	Team	A composite `IWorker` implementation.
Class	ThreadWorker	An `IExclusiveWorker` implemented based on a single thread and a queue.
Function	createMemoryWorker	Create an `IWorker` that does nothing but defer work, to be performed later.
Function	pool	Construct a `Team` that spawns threads as a thread pool, with the given limiting function.

def createMemoryWorker(): (source)

Create an IWorker that does nothing but defer work, to be performed later.

Returns a worker that will enqueue work to perform later, and a callable that will perform one element of that work. (type: 2-tuple of (IWorker, callable))

def pool(currentLimit, threadFactory=Thread): (source)

Construct a Team that spawns threads as a thread pool, with the given limiting function.

Parameters	currentLimit	a callable that returns the current limit on the number of workers that the returned `Team` should create; if it already has more workers than that value, no new workers will be created. (type: 0-argument callable returning `int`)
	reactor	If passed, the `IReactorFromThreads` / `IReactorCore` to be used to coordinate actions on the `Team` itself. Otherwise, a `LockWorker` will be used.
Returns	a new `Team`.
Note	Future maintainers: while the public API for the eventual move to twisted.threads should look something like this, and while this function is necessary to implement the API described by `twisted.python.threadpool`, I am starting to think the idea of a hard upper limit on threadpool size is just bad (turning memory performance issues into correctness issues well before we run into memory pressure), and instead we should build something with reactor integration for slowly releasing idle threads when they're not needed and rate limiting the creation of new threads rather than just hard-capping it.

twisted._threads package documentation

`twisted._threads` package documentation