Hacker News Reader

Comment by fanf2 | Hacker News Reader

Cancellation and backpressure are different things. Backpressure is about not accepting work when there is not capacity to handle it. It is incorrect to accept too much work, hit overload, and respond to the emergency by throwing away partially completed work. That makes the overload worse by wasting effort.

View on HN

the default backpressure response in the BEAM is that when you make a call to another actor, and your call times out because the other actor is too busy, the network temporarily is too closed, etc, etc, YOU die, with no intervention from the service you've called.

Often overlooked on the backpressure side of the .NET implementation fence is the SynchronizationContext/Scheduler system. Easily overlooked because of its very apparent complexity beyond the immediate "it just works" surface level in UI event handlers in WinForms/WPF, you can do all sorts of backpressure management with .NET's Schedulers, and because of the SynchronizationContext "magic" a lot of code doesn't change and doesn't have to have any idea about and can be entirely agnostic from whatever Schedulers that are driving it.

It's something that I'm both surprised and not all that surprised it hasn't made its way into more async/await languages exactly because of that confusing complexity.

I believe that in Python, due to its explicit over implicit philosophy, you could almost fake SynchronizationContext/Scheduler dynamics with a smart enough "event loop" as your outermost async runner, monkey patching coroutine return Futures/Tasks to include CurrentSynchronizationContext/CurrentScheduler information. It even looks like at a shallow skim some of that is designed into the default asyncio event loop system in the form of "custom event loop policies", but in the same skim it seems like its both more complex in its own way than SynchronizationContext/Scheduler (such as its primary job seems to be in handling platform specifics), and cursory searches don't show anyone attempting to use it for backpressure management.

Not that in most cases I would write backpressure management code directly in SynchronizationContext/Scheduler "magic" today: I'd use ReactiveX glue and explicitly define Schedulers there and/or make use of "off-the-shelf" RX backpressure combinators. But the low level capability at the .NET SynchronizationContext/Scheduler level is an often overlooked "magic" to async/await that can get results from existing async/await code without needing to rewrite existing async/await code. (I think the fact that RX.NET itself can piggy back off of that low level most directly as opposed to in other languages/environments implementing its scheduler support and backpressure work with less low level underlying support is also easy to overlook that .NET seems to be doing it all more cohesively under the hood.)

True, but cancellation tokens allow you to alleviate backpressure by safely dropping in-flight requests once you hit a given threshold instead of adding to an unbounded scope.

Reply on news.ycombinator.com