[SERVER-930] Flow control for ASIO Created: 18/Dec/09 Updated: 06/Dec/22 Resolved: 02/Nov/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Mathias Stearn | Assignee: | Backlog - Service Architecture |
| Resolution: | Won't Do | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Participants: |
| Description |
|
Currently we are relying on TCP for flow control. We will need to work something else out before we can switch to ASIO. |
| Comments |
| Comment by Lauren Lewis (Inactive) [ 02/Nov/21 ] |
|
The Service Arch team is in the process of cleaning up tickets in the backlog. This ticket has not been updated in two years so we are closing it. Please reopen if you think this change is valuable. |
| Comment by Dwight Merriman [ 03/Feb/16 ] |
|
@mathias would you not get WOULDBLOCK from the OS in that situation and could select for that to clear? Long time since I have used that stuff. (Not that doing the above isn't quite involved if you are in middle of a long sequence of code. Although IIRC the main client/server message loop gets out of locks before doing a send for this reason, so maybe it isn't too bad usually.) Variation is if empirically this is not a big problem, just let it block and implementation is a hybrid of async and synchronous. Just need some dynanism to thread pool size. |
| Comment by Eliot Horowitz (Inactive) [ 28/Apr/10 ] |
|
deferring asio for now |