[Twisted-Python] Understanding Deferreds/callback further

Phil Mayers p.mayers at imperial.ac.uk
Thu Nov 9 07:00:35 EST 2006

Yi Qiang wrote:
> On 11/8/06, *Phil Mayers* <p.mayers at imperial.ac.uk 
> <mailto:p.mayers at imperial.ac.uk>> wrote:
>         The "Monitor" portion of the clients seem superfluous - what
>         does it
>         achieve that having the worker submit the completion does not?
> Also, another reason why I wanted a monitor is because then I only have 
> to establish on connection to the PB server, vs having each worker 
> establish it's own connection, or passing around the remoteobj. 

(there's no need to CC me, I'm on the list)

Ok fine, you want a (superfluous IMHO) instance of a monitor class.

Do this:

class Worker:
   def issueJob(self, job):
     # return a deferred
     return reactor.callInThread(nonGILnonBlocking, job)

class Monitor:
   def connect(self):
     factory = pb.PB.ClientFactory()
     reactor.connectTCP(host, port, factory)
       self.connected, self.connectfailed

   def connected(self, remoteobj):
     self.remoteobj = remoteobj
     self.workerpool = SomeWorkerPool()
     for worker in self.workerpool:

   def startWorker(worker):
       self.startWorker2, worker
       # startWorker2 returns a deferred - the callback chain will be
       # paused here when that happens and continued when *that* deferred
       # finishes, with the callback value

   def startWorker2(self, job, worker):
     deferred = worker.issueJob(job)
     return deferred

   def workerDone(self, result, worker):
     self.remoteobj.callRemote('jobDone', result)

   def workerFailed(self, failure, worker):
     self.remoteobj.callRemote('jobFailed', failure)

I *still* think you need a job ID number to key successes and failures 
at the server side.

More information about the Twisted-Python mailing list