News for hackers. Stuff that matters.
Re:Async destructors, async genericity and completion futures by bsder on Thursday June 02, 2022 @05:20PM (#31600639)
> the paper would benefit from a Conclusions/Recommendations. (I know, that's lazy of me, but I think it would be a nice finish.)

Conclusion: Don't use async/await?

I'm being somewhat glib, but posts like these are really a gigantic warning sign that the abstraction may not be correct.

Async/await is supposed to make things easier, no? If the abstraction is leaking this much, you should start asking if it's actually making things easier. (Seee: Java's Thread.stop()/Thread.interrupt() issues for prior art)

> I started reading this hoping to get some insight into creating a way to abort an in flight promise

At the bottom, the issue you are asking is "How do I smack the event loop Executor that async/await is hiding so my Promise can run out its error/abort code to completion?"

And this is my primary beef with async/await. All of the attempts to hide the Executor are very leaky and demand lots of gymnastics to work around. This is doubly true in a non-GC language like Rust where you can't count on a global thing like the GC to clean everything up eventually.

I suspect that there is something to async/await, and I am grateful for people thrashing it out. However, I suspect that people need to shake off their Javascript-colored glasses before we get down to the "real" abstraction.

There are no comments on this comment yet.