Go to the latest version of this document.
search in docstrings

Search bar offers the following options:

- Term presence. The below example searches for documents that must contain “foo”, might contain “bar” and must not contain “baz”: `+foo bar -baz`
- Wildcards. The below example searches for documents with words beginning with “foo”: `foo*`
- Search in specific fields. The following search matches all objects in "twisted.mail" that matches “search”: `+qname:twisted.mail.* +search`

  Possible fields: 'name', 'qname' (fully qualified name), 'docstring', and 'kind'. Last two fields are only applicable if "search in docstrings" is enabled.

- Fuzzy matches. The following search matches all documents that have a word within 1 edit distance of “foo”: `foo~1`

Results provided by Lunr.js

# ``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 `__init__.py`:

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.
Exception | `AlreadyQuit` | This worker worker is dead and cannot execute more instructions.
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
2-`tuple` of (`IWorker`, `callable`) | a worker that will enqueue work to perform later, and a callable that will perform one element of that work.

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

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

Parameters
currentLimit:0-argument callable returning `int` | 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.
threadFactory:callable returning a `threading.Thread` | Factory that, when given a `target` keyword argument, returns a `threading.Thread` that will run that target.
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.