twisted._threads

package documentation
(source)

Twisted integration with operating system threads.

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.

Returnsa 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.

ParameterscurrentLimita 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)
threadFactoryFactory that, when given a target keyword argument, returns a threading.Thread that will run that target. (type: callable returning a threading.Thread)
Returnsa new Team.
NoteFuture 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.
API Documentation for Twisted, generated by pydoctor 20.12.1 at 2021-02-28 19:53:36.