Changes between Version 2 and Version 3 of Ticket #1191, comment 12


Ignore:
Timestamp:
2010-09-07T05:59:18Z (14 years ago)
Author:
zooko
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1191, comment 12

    v2 v3  
    3232So at {{{local#231 23:01:59.969}}} the request is retired but the resulting eventual {{{got_shares}}} won't happen until {{{local#255 23:01:59.977}}} which is shortly after the {{{loop}}} at {{{local#247 23:01:59.973}}} which said {{{no_more_shares, ever}}}, which set a flag named {{{_no_more_shares}}} in the {{{SegmentFetcher}}} so that the next time {{{SegmentFetcher._do_loop}}} runs then it gives up and says {{{ran out of shares}}} at {{{local#253 23:01:59.976}}}.
    3333
    34 Now [attachment:1191-fix.diff] makes it so that when {{{loop}}} decides {{{no_more_shares, ever}}} then it sets an eventual task to set the {{{_no_more_shares}}} flag in {{{SegmentFetcher}}} instead of doing it immediately. Is this guaranteed to always prevent this bug? I guess it is because when the {{{_request_retired}}} ({{{local#231 23:01:59.969}}}) is done immediately then during that same tick the {{{got_shares}}} ({{{local#255 23:01:59.977}}}) is put on the eventual queue, so when the setting of {{{_no_more_shares}}} is put on the eventual queue it will always go take effect after the {{{got_shares}}} does.
     34Now [attachment:1191-fix.diff] makes it so that when {{{loop}}} decides {{{no_more_shares, ever}}} then it sets an eventual task to set the {{{_no_more_shares}}} flag in {{{SegmentFetcher}}} instead of doing it immediately. Is this guaranteed to always prevent this bug? I guess it is because when the {{{_request_retired}}} ({{{local#231 23:01:59.969}}}) is done immediately then during that same tick the {{{got_shares}}} ({{{local#255 23:01:59.977}}}) is put on the eventual queue, so when the setting of {{{_no_more_shares}}} is put on the eventual queue it will always take effect after the {{{got_shares}}} does.
    3535
    3636Okay.