4 ms·
It's conceptually a different thing to "await" and to "stop execution till the thing I am waiting for happens" In the first case I am telling an executor what
by sharikous 5y ago
It's conceptually a different thing to "await" and to "stop execution till the thing I am waiting for happens"
In the first case I am telling an executor what it has to do (it has to execute the thing then continue inside my function)
In the second case I am myself blocked into a state that will be unblocked when the thing returns.
That is in the first case my function must be of a type that can be stopped and continued and I need to save its state somewhere.
In the second case I don't need the ability to stop and continue my function.
That makes for two kinds of functions at some level. Low level languages will expose that. High level languages will hide it.
But there is a growing request for functions that can be both. I think that zig has them
- cuteboy19 5y agothe requirements of the second case are a subset of the first case, so then it should be theoretically possible to await inside non async functions. Seems to me that JS simply doesn't implement this ability, but it could if it wanted to
- endorphine 5y ago> That is in the first case my function must be of a type that can be stopped and continued and I need to save its state somewhere. And that state is saved in the heap, I presume? Can you provide a concrete example perhaps? I get that the state in case of green threads (Goroutines for example) is saved in the call stack itself. Where all this is saved in async/await?
- gpderetta 5y agoThe typical implementation of async/await need to store (the equivalent of) a single activation frame (as opposed to a stack of activation frames). This is normally stored separately on the heap, but it can be embedded in some other (heap allocated object) or even stored directly on the stack of some thread, depending on language, usage patterns and optimization capabilites.