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.

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.

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.

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.)

This is the direction JavaScript is going as well. Having used cancellation tokens in C#, I quite like the pattern.

https://developer.mozilla.org/en-US/docs/Web/API/AbortContro...

How's it different than Go's context.Done() channel? Similarly it bubbles up everywhere the context is passed immediately, letting you terminate concurrent routines.

I've used both .NET async/await (4 years ago) and Go ever since. The semantics and feel is nearly the same, the look is different.

IMHO, being able to throw the error and it moving magically up the async stack (aka try/catch) makes it easier to get started while go makes it easier to maintain by forcing you to design a system around channels. This opinion is coming from a decade of .NET but just a few months of go experience so it's very skewed.

> All .NET async APIs take an optional cancellation token parameter [...] The best part about this is that it pervades the entire .NET runtime, the APIs, code examples, and has excellent documentation on correct usage patterns.

This statement is completely false. The .NET runtime is inundated with bad code examples resulting in deadlocks with async code.

In my professional experience, the WriteableBitmap class is completely unusable. All official code samples exhibit the same brokenness.

They all tell you to do the same thing: lock() on the WriteableBitmap object, get the buffer, perform an update the buffer, unlock() on the WriteableBitmap object. But you try to lock() on a backgroundworker (the sane thing to do) and it fails because lock() can only be called from the UI thread. So you lock() on the UI thread, async into a backgroundworker (the second most sane thing to do) to update the buffer, and boom, WPF deadlocks. The official Microsoft UI framework uses .Lock(), not .TryLock(), and you are deadlocked forever. There is no solution to this problem. No solution exists. Abandon all hope ye who enter here.

C#/.NET+async is horrible. Maybe this is the best async implementation that's been done, but if that's the case, the best implementation is worse than starting a new thread every time you need to block on IO. The only way to write good async C#/.NET code is to not write async C#/.NET code. But guess what? As you said, C#/.NET is inundated with async APIs, and it falls down every time you blink at it.

C++ is looking to standardize async/await into the language. I think I'd rather pick up growing corn.

https://docs.microsoft.com/en-us/dotnet/api/system.windows.m...

How are you "asyncing" to the "backgroundworker" thread? Await? Task.run? Are you using a .Return?

I can't see your code, but this sounds more like a misunderstanding of the requirements around a UI thread and the task scheduler than any issue with async.

https://medium.com/rubrikkgroup/understanding-async-avoiding...

And the below seems to be a correct implementation of your desired functionality.

https://stackoverflow.com/questions/9868929/how-to-edit-a-wr...

Yes, I don’t understand why original commenter is so angry about c#/.net. Maybe a bad experience?

Async .net may have some pitfalls but it is overall versatile which was the original sentiment anyways...

First of all, your original post claimed that the official documentation is good. I posted an example of where the official docs are dumb and wrong. You posted a random blog article and a stack overflow answer as a rebuttal. Just so we're clear, you agree that the official documentation is dumb, wrong, and incomplete?

Second, the "seems to be correct" article you linked is what we did. It's a sensible, logical solution to the problem. Which is why we wrote it that way to begin with. Hell, we might have copied it directly from that SO answer.

It doesn't work. It deadlocks. You call out to the UI thread dispatcher, lock the object, then go back to doing stuff on a background thread. Some time later, the UI thread is updating the UI, and it tries to update your element, and it tries to lock on the lock object. (it can't, because it's already locked) Some time later, the background task is done. It schedules a task on the UI thread to unlock the object. There's a problem though: the UI thread is locked on a mutex. A single hardware thread cannot wait on both a mutex and the task queue at the same time. Deadlock.

Just because it's the highest voted answer on SO doesn't mean that it isn't completely wrong.

The second highest voted answer states that what the questioner is asking for is impossible. This answer is the correct one. Our least bad solution to this problem is to update a buffer owned by the background thread, and then use the UI thread to copy pixels from the background thread's buffer to the UI thread's buffer. Lock, copy the buffer, unlock, without ever relinquishing control of the UI thread. This solution is not ideal from a performance standpoint, but at least it doesn't deadlock.

C#/.NET's async is fine if you're not doing anything more complicated than querying a database or paying data around on a socket. It falls down really hard if you start tickling its underbelly.

> But you try to lock() on a backgroundworker (the sane thing to do)

That’s just a leaky abstraction. Updating image from background thread is a sane thing to do from general-purpose programmer POV. To understand why it’s not so good idea, and why it’s not supported, you need to know what happens under the hood. Specifically, how 3D GPU hardware works and executes these commands.

> No solution exists.

From graphic programmers POV, the sane solution — only call GPU from a single thread. In D3D11 there’re things which can be called from background threads. It’s possible to create new texture on the background thread uploading the new data to VRAM, pass the texture to the GUI thread, then on the GUI thread either copy between textures (very fast) or replace textures destroying the old one (even faster). Unfortunately, doing so is slower in many practical use cases, like updating that bitmap at 60Hz: creating new resources is relatively expensive, more so than updating preexisting one.

Python has something similar, you can cancel() any async task and it will throw a CancelledError inside the ongoing operation.

I'm not sure how it would solve backpressure though, because canceling a task is normally done by the caller, while backpressure comes from the other direction of the call stack.

Cancel in Python and a cancellation token are very different concepts. Cancellations in Python are not passed through the same way and you can’t await a cancellation.

have you tried using RX with <any language>? it solves these concerns beautifully, albeit with a possibly steep learning curve.

Yeah I agree with yourself and the the writer that cancellation is necessary.

I’m not sure I agree with the writer that async should handle back pressure. To me that should be handled more explicitly by something purpose built, e.g .NETs Channel type.