1. 07 Jan, 2021 11 commits
    • Florian Fischer's avatar
      [IO] remove partial completion feature · 3b7a60ff
      Florian Fischer authored
      Not supporting partial completions for send, write, read makes
      a lot of code paths way simpler, removes Futures from the globalIo and
      allows more inheritance.
      I don't think partial completion support is worth the hassle.
      Partial completions cancel all dependent requests. Resubmitting some
      in the chain breaks the semantic.
      The global completer does not need to handle requests in its own io_uring.
      We don't need templates for submit because submit works only from within
      the Runtime. This allows submit to be virtual and be overridden by
      Futures which issue a syscall before they submit them selves to the io_uring.
      This and the absence of partial completions save a lot of conditions on
      the fast path.
    • Florian Fischer's avatar
      [IO] improve Future documentation · cfd7ace8
      Florian Fischer authored
    • Florian Fischer's avatar
      [IO] don't set errno when awaiting a Future · cbbe94d8
      Florian Fischer authored
      Set errno only when using the POSIX like IO functions.
      Future::wait will return either an negative error code or a positive result
    • Florian Fischer's avatar
      Add timout support through AlarmFuture and TimeoutWrapper · 42b6ab54
      Florian Fischer authored
      AlarmFutures implemented IOURING_OP_TIMEOUT requests,
      TimeoutWrappers are IOURING_OP_LINK_TIMEOUT requests and add the
      wrapped Future as its dependency to link the timeout with it.
    • Florian Fischer's avatar
      [IO] add Future subclass API, allow Futures to be linked · 2ab9445b
      Florian Fischer authored
      Introduce specialized Future subclasses API to the IO subsystem.
      For each io::OPERATION request there exists a Class named <Operation>Future
      (e.g. AcceptFuture(...), SendFuture(...)) with a constructor matching
      the definitions of the known POSIX functions (e.g. accept(2), send(2)).
      Using Futures objects instead of the the POSIX like interface provided
      by io.hpp gives more Flexibility to the memory management as well
      as the possibility to link IO requests.
      Futures can be linked by declaring one the dependency of another.
      A Future is only signaled if all IO requests it depends on are completed.
      WriteFuture wf(fd, str, str_len, 0);
      ReadFuture rf(fd, buf, buf_len, 0);
      Submitting a Future will also submit all its dependencies to the IO
      Manually submitting a Future B which is the dependency of another Future A
      before Future A is undefined behavior.
      If an IO operation in a chain fails all dependent IO operations will
      be completed with -ECANCELED.
      Declare the single Future constructor as protected so a user can not
      instantiate a plain Future object.
    • Florian Fischer's avatar
    • Florian Fischer's avatar
      [IO] refactor the public IO interface · 80a44f96
      Florian Fischer authored
      * use CamelCase to be more in line with the rest of the code base
      * futures are now always submitted to a specific IoContext
      * this moves all io_uring related code into the IoContext
      * add new static IoContext functions to obtain IoContext objects
    • Florian Fischer's avatar
    • Florian Fischer's avatar
      [IO] improve comments and move code · 37114457
      Florian Fischer authored
    • Florian Fischer's avatar
    • Florian Fischer's avatar
      [IO] restructure IO subsystem · 6c05f216
      Florian Fischer authored
      Split up and move all IO related code into emper/io.
      The intended way to use emper's IO subsystem is by including either
      the io.hpp for C++ or the emper.h header for C code.
      All components of the IO subsystem are now encapsulated in emper::io::IoContext.
      An IoContext consists of a io_uring, an Actor to submit requests to the io_uring,
      a thread that collects cqes from the io_uring and unblocks waiting fibers as
      well as some debug and statistic variables.
      In theory there could exist more than on IoContext but the public IO
      API defined in io.hpp will use the one created and set by the runtime.
      When a runtime is instantiated it will create a new IoContext which will
      schedule a SubmitActor and start the completion thread.
      This means the IoContext must be created after the Scheduler.