mpeklar

When considering this issue alongside with RFD 397, it seems to me that the problem is actually using future drops as an implicit (!) cancellation signal. This makes drop handlers responsible for handling every cancellation-related task, which they are not very good at. If a future is not immediately dropped after selecting on it, you get futurelock, and if it is, you get an async cancellation correctness problem, where the only way to try and interact with the cancellation execution flow is to use drop handlers (maybe in the form of scope guards).

Sadly, the only solution I know of is to use an explicit cancellation signal, and to modify ~everything to work with it. In that world, almost all async functions would need to accept a cancellation parameter of some sort, like a Go Context or like the tokio-utils CancellationToken, and explicitly check it every time they await a function. The new select!-equivalent would need to signal cancellations and then keep polling all unfinished cancellation-aware futures in a loop until they finished, and maybe immediately drop all non-aware futures to prevent futurelock. The entire Tokio API would need to be wrapped to take into account cancellation tokens, as well as any other async library you would want to use.

A lot of work, and you would need to do something if cancel-aware futures get dropped anyway. What a mess.

Yes, but since they control the background service too, they can just update the service to make it respond to CORS requests.

This DOES need to be put into context. It is very, VERY old, so old it even predates all modern congestion control algorithms. The timer problems were solved by Van Jacobson in 1988, who replaced the fixed beta parameter with a mathematical variance estimator, which made solved the convergence problems. The slow connection start problem was resolved using the slow-start algorithm (which ramps up exponentially). The congestion problem was solved by using exponential backoff and linear ramp-up after slow start, which solved the "retransmit storm" problem which had plagued ARPANET since the beginning. You can read about those improvements in [0], straight from Van Jacobson himself.

His scheme became known as TCP Reno, and was the basis for almost every future congestion control algorithm (CUBIC, Vegas, Chicago, Compound), until BBR (also by Van Jacobson), which operates on different principles [1].

[0]: https://ee.lbl.gov/tcp.html [1]: https://research.google/pubs/pub45646/