4 ms·

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

UncleEntity 8y ago
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).
- Matthias247 8y ago
  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.
  - gpderetta 8y ago
    I think seastar futures are allocation free. Standard c++ futures are not really a paragon of efficiency or good design. Still no GC though.
    - Matthias247 8y ago
      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.hh 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.
      - gpderetta 8y ago
        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.
SamReidHughes 8y ago
C++ has futures libs too. See the Seastar framework, for an example.

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

Matthias247 8y ago
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.
- gpderetta 8y ago
  I think seastar futures are allocation free. Standard c++ futures are not really a paragon of efficiency or good design. Still no GC though.
  - Matthias247 8y ago
    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.hh 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.
    - gpderetta 8y ago
      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.

SamReidHughes 8y ago

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