Hacker News Reader

Comment by nercury | Hacker News Reader

I want to reflect on that this is still done without any garbage collector.

Why would anyone assume that a GC is needed for async/await?

The Future object seems to do the all bookkeeping needed by the borrow checker (which I believe is what rust uses to track the lifetime of objects).

Maybe because most future implementations (e.g. in Javascript, the proposed C++ solution, Seastar, etc) work by scheduling a continuation on an event loop. Which obviously requires at least some form of dynamic memory for queuing up these continuations.

I think seastar futures are allocation free. Standard c++ futures are not really a paragon of efficiency or good design. Still no GC though.

I haven't read the code, but there are 2 areas where I expect allocations:

- The continuation which is passed to .then, and which is typically a closure, must be type-erased, which requires an allocation. Storing the continuation in a std::function would allocate too. A short glance at https://github.com/scylladb/seastar/blob/master/core/future.... also confirms that there is a make_unique there.

- Since continuations are most likely not called inline on completion but deferred into the next eventloop iteration there needs to be a dynamically sized queue to hold the ready continuations. I am not 100% sure if that's the case for seastar too, but I would guess so.

I do not think the continuation is type erased. I belive that then, at least optionally (depending on the actual futurator passed in) can returns a future whose type encodes the continuation type and stores it inline.

The queue might be dynamically sized which might eventually require allocation, but that can be ammortized across many futures. A large enough queue might never require reallocation.

I'm also not 100% sure as I have never used seastar.

C++ has futures libs too. See the Seastar framework, for an example.

Reply on news.ycombinator.com