a.t.OrderedItemProducer(PoolUser) : class documentation
Implements interfaces: twisted.internet.interfaces.IPushProducer
Produces blocking iterations in the order they are requested via an asynchronous function call.
I am an implementor of Twisted's
IPushProducer interface that produces an iteration to a blocking call fb for every time you call a non-blocking item-generating function fb via my
produceItem method. Significantly, the items are buffered as needed so that the iterations appear in the order of the calls to
produceItem that generated them, not necessarily in the order in which they are actually generated.
Start things off by constructing an instance of me, with an existing task queue if you have one you want me to use, and then running
start with your blocking f-args-kw combination. Then call
produceItem repeatedly with whatever f-args-kw combination results (eventually) in new items to iterate. These calls may return deferred results and should not block.
When you are done having me produce iterations, call
stop. Whatever loop the blocking-iterator call is in will then terminate and function fb should end.
Inherited from PoolUser:
|Class Method||setup||No summary|
|Class Method||deferToThreadInPool||Runs the
|Method||pool||Returns a reference to the class-wide threadpool, starting it if this is the first time it's been used.|
Starts the blocking function call
fb(i, *args, **kw) that relies on my
Consumerator instance i for iterations, in traditional blocking fashion. The function must accept
i as its first argument, and can also accept further arguments
*args and keywords
**kw, which you can specify in your call to
fp(*args, **kw) to generate an item that I produce as an iteration to whatever blocking call was (or will be) set running via
While I am running, the returned
Deferred fires after the call to fp with the item value produced by the call to f. You don't need to do anything with these deferreds if you don't want to use them for concurrency limiting; they are accounted for in
If an exception is raised during the call, the dFinished callback is called with a corresponding
Failure object and iterations will be stopped. This makes more sense than firing an errback of the
Deferred returning from this
produceItem method, because it's the end result of calling
stop to indicate that iterations are done. *That* is when the user should expect a status of the overall item-producing operation.
stopProducing method has been called, I no longer produce iterations and calls to this method do not run fp. The returned
Deferred fires immediately with
def stop(self, failureObj=None):
Call this to indicate that iterations are done. After any pending calls from
produceItem are done, my
Consumerator will raise
StopIteration for the blocking iteration-caller in fb and that function should exit. Whatever value it returns will fire the
Deferred that is returned here.
Deferred may have fired already, if fb exited early for some reason, or with a
Failure object that may have been generated either by the iteration caller or by a call to the fp function of
Repeated calls to this method make no sense and will be rewarded with deferreds immediately firing with