Hi again Alexey I guess it's clear from all the other comments that we should call what you're after something other than a Deferred. I agree with all the others that Deferreds are great as they are, and especially with the comment that you can/should use them as building blocks in the class you actually want. As for what it is that you actually want, it still sounds like something in the middle of the various things provided for you by DeferredList, the reactor itself, the code I pointed you to, LoopingCall, etc. I know it's not any of those things exactly, but it's some mixture of them. The other thing that comes to mind is defer.inlineCallbacks. You can use it to simply implement complex logic, state machines, multiple unpredictable needs and events, etc., and the caller of an inlineCallbacks decorated function gets a normal deferred back which will deliver the final result(s), if any. Using inlineCallbacks you can write fairly "natural" (i.e., synchronous-looking) code that's calling functions that return deferreds, yielding them, getting their results, and continuing as though nothing had happened. You can write state machines, you can yield DeferredLists, etc. You can do many many things, and the code you write doesn't have to look bizarre. defer._inlineCallbacks (note the underscore) takes care of interacting with your deferred yielding code and getting the results of the intermediate deferreds back to you. Note that the functionality of inlineCallbacks (and DeferredList and LoopingCall) is built upon the humble Deferred. That's pretty strong evidence that the class you'll end up writing can also offer great flexibility and generality and also be based just on Deferreds. Understanding inlineCallbacks might be another piece of the puzzle in seeing how to do what it is you need. (Apologies if you already do understand inlineCallbacks - I mention it because no-one else has and I think it's probably relevant). Terry