Hi Jean > Concerning the concept of the deferred, why is it more useful to go with > a deferred which gets consumed and can only be fired once?
I can't speak for the Twisted devs, but my #1 reason would be that it's just simpler that way (and Deferreds are already complex enough). > In my small script I realize I need to take special care that the > deferred has not been used, and that I must recreate explicitly a > deferred for each network request. In a parallel world someone might have > come up with a deferred concept which happily fires the callback as many > times as there data coming back from the server. Is it a dumb idea? No, I don't think so. I've done some thinking and playing along these lines. At one point I thought about a Deferred class that could be called multiple times, but decided the code changes were too ugly. Recently I did some experiments in which Deferreds could be re-used. The first observation was that the time taken to create Deferreds is really negligible. That is, just re-using an already allocated object doesn't save you much. More interestingly, the adding of call/errback functions to a Deferred does take significant time. I don't have the details of what I did handy, but from memory I managed to get about a 2x speedup in a simple test when Deferreds were having about 5 call/errbacks added to them. I wrote a class that allowed you to reset a Deferred, leaving the call/errback chain on it (snipping off other things that might have been added to the chain), and there was also a DeferredPool class that could hand you back an already prepared Deferred (or make you a new one if the pool was empty). I.e., if you're in a situation where you're repeatedly using Deferreds and putting exactly the same call/errbacks on them, you might get a win by resetting and reusing already fired Deferred. On the other hand, you'd also be a social pariah :-) If anyone wants more details, I'm happy to dig up my experimental code. It was fun and it seemed to work just fine. > Could the deferred design be part of the solution to the network problem > of two requests passing each other as each ends is not yet aware that the > other has just sent a request? Buggy networks nodes would expect a > response but get a request instead and go crazy... OK, I'll leave that one for someone else... T _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
