twisted._threads.__init__ module documentationtwisted._threads
          View Source
          
        
      Twisted integration with operating system threads.
| Class | ThreadWorker | An IExclusiveWorker
implemented based on a single thread and a queue. | 
  
| Class | LockWorker | An IWorker 
implemented based on a mutual-exclusion lock. | 
  
| Interface | IWorker | A worker that can perform some work concurrently. | 
| Class | AlreadyQuit | This worker worker is dead and cannot execute more instructions. | 
| Class | Team | A composite IWorker 
implementation. | 
  
| 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. | 
  
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. | |