Maybe I misspoke. The way I understand it, is that deferreds do not get CPU time until the reactor resumes control. Once the reactor gets control it allows events to happen, some of which may be deferreds. I'm not sure what does the scheduling or what order deferred objects get control of the thread. I had assumed that the reactor or whatever scheduler kicked off deferreds in the order that they were created. Once that deferred chain got control of the main loop it would run to completion and the next event whether a deferred or something else would run. In my case I need the deferred to wait until my commandComplete function runs. Is the aDeferred.callback(result) the trigger that starts the deferred? If that is the case, then I understand how my current code is working and I understand that there IS no scheduler for the deferreds. Deferreds fire when a callback or errback function is called on them. End of story and no magic done behind the scenes. Jon -----Original Message----- From: twisted-python-bounces@twistedmatrix.com [mailto:twisted-python-bounces@twistedmatrix.com] On Behalf Of Itamar Shtull-Trauring Sent: Friday, December 09, 2005 11:29 AM To: Twisted general discussion Subject: RE: [Twisted-Python] RE: waiting on transport return On Fri, 2005-12-09 at 11:02 -0700, jmbenski@micron.com wrote:

After looking at the code a bit more and your change below, I'm surprised that my code works. Why isn't the reactor kicking off my deferreds that are stored in the queue?

Deferreds have nothing to do with the reactor. So, doing aDeferred.callback(result) or .errback(error) are the only way it gets a value. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python