[SERVER-20471] The connection pool's ASIOTimer needs more synchronization and shared state to work with asio's timer Created: 17/Sep/15 Updated: 07/Oct/15 Resolved: 18/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking |
| Affects Version/s: | 3.1.8 |
| Fix Version/s: | 3.1.9 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Mira Carey | Assignee: | Mira Carey |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Platform 9 (09/18/15) |
| Participants: |
| Description |
|
asio's underlying timers have fairly loose behavior on cancel. Specifically, a cancelled callback can be invoked with or without the cancelled error code. In the case of dtors that invoke callbacks, this means that we must have a shared pointer around with a lifetime longer than the actual ASIOTimer so that we can check if we've been cancelled (because we can't look at the original object). In addition, we can call cancel/set multiple times, so we should keep a counter around so we know if the callback we're in should be invoked, even if the timer itself is currently active |
| Comments |
| Comment by Githook User [ 17/Sep/15 ] |
|
Author: {u'username': u'hanumantmk', u'name': u'Jason Carey', u'email': u'jcarey@argv.me'}Message: asio's underlying timers have fairly loose behavior on cancel. In the case of dtors that invoke callbacks, this means that we must have In addition, we can call cancel/set multiple times, so we should keep a |