Changes between and of Initial VersionVersion 12Ticket #411

Show
Ignore:
Timestamp:
11/15/2008 06:19:39 PM (5 years ago)
Author:
glyph
Comment:

While the specific optimization in question might not work, there's definitely something we can do to improve this situation.

Brian Warner did a really good writeup of the implications of this problem  in a ticket on the allmydata tracker which he later copied as  a message to the Twisted list.

However, the suggested fix there (reactor.eventually()) is wrong, in my opinion. You don't need to rip the whole stack in order to fix this problem, only the portion that is already running inside defer.py.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #411

    • Property status changed from new to reopened
    • Property cc oubiwann added
    • Property component changed from to core
    • Property summary changed from Deferreds are good at blowing the stack to Returning a Deferred from the callback of another Deferred too many times results a RecursionError
    • Property priority changed from high to normal
    • Property keywords core removed

  • Ticket #411 – description

    initial v12  
     1Returning a Deferred from a callback to another Deferred will result in a RecursionError if it is done too many times with Defererds that have already fired. 
     2 
     3The traceback in question doesn't have any application code on it and can be very difficult to interepret.  At worst, Twisted should alert you to what has happened in a comprehensible manner; however, it should really be possible to just return Deferreds from callbacks indefinitely. 
     4 
     5This is related to [ticket:3229 the more general issue of calling a one Deferred's callback from another Deferred's callback], but we can fix this specific case in a potentially more general way.