1. 03 Nov, 2021 2 commits
    • eta's avatar
      tor-proto: Use a dedicated sender for channel cells, make full-duplex · db6b9116
      eta authored
      @nickm pointed out that refactoring tor_proto::channel's Reactor to do
      sending as well meant that it could only send or receive, but not both,
      simultaneously, which was bad!
      To fix this, rewrite Reactor::run_once to use a handcrafted future (with
      futures::future::poll_fn) that can handle the logic required to push
      items onto the sink asynchronously (i.e. checking that it can be written
      to before trying to do that, and then flushing it).
      This also means we don't use select_biased! any more, and just handroll
      that logic ourselves; as a small bonus, we can now process all 3 kinds
      of message in one run_once() call, instead of having to do only one of
    • eta's avatar
      Get rid of tor-proto's ChannelImpl, and use the reactor more instead · e8e9699c
      eta authored
      Instead of awkwardly sharing the internals of a `tor-proto` `Channel`
      between the reactor task and any other tasks, move most of the internals
      into the reactor and have other tasks communicate with the reactor via
      message-passing to allocate circuits and send cells.
      This makes a lot of things simple, and has convenient properties like
      not needing to wrap the `Channel` in an `Arc` (though some places in the
      code still do this for now).
      A lot of test code required tweaking in order to deal with the refactor;
      in fact, fixing the tests probably took longer than writing the mainline
      code (!). Importantly, we now use `tokio`'s `tokio::test` annotation
      instead of `async_test`, so that we can run things in the background
      (which is required to have reactors running for the circuit tests).
      This is an instance of #205, and also kind of #217.
  2. 02 Nov, 2021 19 commits
  3. 31 Oct, 2021 2 commits
  4. 29 Oct, 2021 17 commits