Async musings

Nice, have you done any benchmarks yet? Really curious how it compares to stdlib async.

Async musings

Sorry. If it takes me more than a minute to reproduce some obscure nim bug, I usually give up. And I'm sorry but I'm not buying that I have to `nimble install ncurses` (and even them I'm getting some unrelated error) because you can't reduce the sample enough.

Async musings

Hi Juriy, sorry if this is a bit off topic, do you have an idea how to fix bug 19984? It has to do with closure iterators.

Async musings

I'm finally at the point to show [something](https://github.com/yglukhov/yasync) with passing tests :) Albeit run it you'll need to use latest nim devel plus [this patch](https://github.com/yglukhov/Nim/commit/9758922ae702e0d005756111c9fb0badc3ed90d6) which "fixes" [this bug](https://github.com

Async musings

> If I remember correctly it's fixed in both chronos and lately asyncdispatch > by nullifying the future ( it's a bit more involved than that - the closure iterator ends up referring to the future and vice versa in the generated code - setting futures to nil aggressively removes some references

Async musings

@dom96 > From what I can see you have effectively extracted the closure iterator code > from the compiler into a macro. Well yes, except I haven't done it, but intend to do so :) > I don't think this invalidates your work, like I said above I think putting > this in a macro is a win anyway and

Async musings

> I'm curious, what is the benefit of building a state object manually this way > over using a closure iterator? Off the top of my head, there are two annoying problems with the giant-closure-iterator approach: * lifetimes are awful - if you send some data, the lifetime of the data you pass

Async musings

This seems quite similar to where I wanted to drive CPS to, having everything objects and only use ref when needed (JS target or escaping continuations). In C, to avoid pitfalls outlined by @dom96, I would use union types, like this

Async musings

Really awesome to see your approach focus on keeping semantics the same (or as close as possible) to existing async in Nim. I think adoption for something that forks the semantics/API will be difficult, especially if the improvements over the existing implementation are relatively niche. >From

Async musings

> Should there be a way to call closure iterator over preallocated environment, > it might invalidate most of my work so far :). But currently it is not > possible, or is it? No, but it should be added.

Async musings

Initially I wanted to reimplement state splitting in a macro, as it would allow for easier experimenting with the transformation algorithms. Doing this in compiler code is arguably more cumbersome. Then it also gives me the full control over memory management and layout. But your question is ac

Async musings

I'm curious, what is the benefit of building a state object manually this way over using a closure iterator? I've experimented with various versions of async systems myself in the past, but I've always built them around closure iterators as the transformation is much easier to do, and as far as

Async musings

A while ago I started playing with a yet-another async system, borrowing ideas from existing asyncdispatch, cps, and other sources. My goal was to: * improve dynamic memory situation * preserve the current semantics of async/await as much as possible * do it all in the library code, without