6 ms·

I started reading this hoping to get some insight into creating a way to abort an in flight promise, e.g. async/await pattern for a tower of async functons, and

by sbf501 4y ago

I started reading this hoping to get some insight into creating a way to abort an in flight promise, e.g. async/await pattern for a tower of async functons, and not a Promise.all[]. However, this is so exhaustively well-written then I realized this is a much harder problem. Yes, I know this is Rust, but the syntax and problems are similar for any deferred execution, ESPECIALLY when hardware is sitting at the bottom of the call. While I applaud the author's completeness and attention to detail -- and how they are refreshingly open about certain solutions looking like "hacks" -- the paper would benefit from a Conclusions/Recommendations. (I know, that's lazy of me, but I think it would be a nice finish.)

AgentME 4y ago
A good way across languages to cancel an asynchronous task is by passing a CancellationToken / AbortSignal (Javascript) as an argument. This scales nicely as a task can pass the token onward to any number of other tasks, and the original creator of the token can abort it and all uses of it at any time.
- e12e 4y ago
  Feels like this should be a language feature, though - like how python passes self for objects - or ruby binds self for you?
  - AgentME 4y ago
    Kotlin has "structured concurrency" which I believe automatically handles some cases of this, but I don't fully understand it. I find explicit cancellation tokens without any magic easier to understand.
- sbf501 4y ago
  I remember a github repo like this from ages ago. How is the token used? I assume the token has a function that triggers an abort, but does that mean the downstream code has to constantly check the token, or does it simply generate a fault/exception at the lowest level that bubbles upstream? I'm not sure of the token mechanics.
  - AgentME 4y ago
    It works like your first guess, but it's not so bad. Downstream code has to either check the token occasionally, subscribe to an event from it, or just pass it forward to another function which uses the token. So if you were writing a function that just made a series of network requests, you would make it take a CancellationToken as a parameter, and then you would pass that parameter on to each of the network request function calls inside your function. Then if the token is in the aborted state while any of the network function calls are in-progress, then that network function call will throw an exception which will bubble up through your function, without your function needing to do anything special with the CancellationToken directly.
- zaphar 4y ago
  This is the primary use-case for Contexts in go. It's standard practice to pass contexts through all your concurrent code and abort on the `Cancel` call.
bsder 4y ago
> 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.

by sbf501 4y ago

AgentME 4y ago

A good way across languages to cancel an asynchronous task is by passing a CancellationToken / AbortSignal (Javascript) as an argument. This scales nicely as a task can pass the token onward to any number of other tasks, and the original creator of the token can abort it and all uses of it at any time.

e12e 4y ago
Feels like this should be a language feature, though - like how python passes self for objects - or ruby binds self for you?
- AgentME 4y ago
  Kotlin has "structured concurrency" which I believe automatically handles some cases of this, but I don't fully understand it. I find explicit cancellation tokens without any magic easier to understand.
sbf501 4y ago
I remember a github repo like this from ages ago. How is the token used? I assume the token has a function that triggers an abort, but does that mean the downstream code has to constantly check the token, or does it simply generate a fault/exception at the lowest level that bubbles upstream? I'm not sure of the token mechanics.
- AgentME 4y ago
  It works like your first guess, but it's not so bad. Downstream code has to either check the token occasionally, subscribe to an event from it, or just pass it forward to another function which uses the token. So if you were writing a function that just made a series of network requests, you would make it take a CancellationToken as a parameter, and then you would pass that parameter on to each of the network request function calls inside your function. Then if the token is in the aborted state while any of the network function calls are in-progress, then that network function call will throw an exception which will bubble up through your function, without your function needing to do anything special with the CancellationToken directly.
zaphar 4y ago
This is the primary use-case for Contexts in go. It's standard practice to pass contexts through all your concurrent code and abort on the `Cancel` call.

bsder 4y ago

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