Changes between Initial Version and Version 1 of Ticket #1191, comment 12
- Timestamp:
- 2010-09-07T05:57:59Z (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #1191, comment 12
initial v1 30 30 (Sorry about the wide lines there.) 31 31 32 So 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".32 So 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}}}. 33 33 34 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.
