Building Channels in C++: Part 5 - Writing a select statement

Declaring the Select

The very first thing we're going to do is forward declare our select and define our errors. We will not be setting up every possible template specialization, just the ones we're going to use. This means that our select statement will be forward declared without an implementation - and that's okay. Here's our declaration:

enum class SelectErrors {
  NOT_READY_YET,
};

template<typename ...Args> struct Select;

First part done!

We're using variadic templates to take in all of the cases we're going to do. For instance, we could have a Select<SendCase<int, 5>, ReceiveCase<double,10>, ReceiveCase<std::string,2>>. By having those cases come in as template parameters, we can support multiple types of cases and channels without having to use inheritance.

However, trying to tackle all possible variadic tempaltes is practically impossible. So instead, we'll create specializations for the first element (send or receive), and then have a list of everything else which we forward to the "next" select - which will then reuse our specializations. We will then have a very special terminator specialization which is empty. With this setup, we'll create a list of selects which we can then iterate over at runtime.

While there are compiler limits to variadic template length and recursive depths, for our use case we generally aren't going to run into those without some actually awful code since we're going to be typing every case. Forcing developers to type their cases is totally fine since we're trying to emulate a statement (i.e. language construct) and not a scheduler or runtime capability. And letting the compiler enforce some sort of constraint on how crazy developers get is often a good thing (we don't want 10,000 line select statements). Let's move on to actually defining logic for our select.

Selecting sends

Our select should be able to handle our send case. It should call attempt's send, and if it works it should quit. Otherwise, we should try the next statement. The type of the next select will be determined by a variadic template. We, the developer, don't need to know what that type will be. That's the compiler's job. We just have to ensure all of our specializations have a step method with the same signature. So, here's our send case.

template<typename T, size_t Capacity, typename Callback, typename ...Args>
struct Select<SendCase<T, Capacity, Callback>, Args...> {
  using Case = SendCase<T, Capacity, Callback>;
  using Next = Select<Args...>;
  Case sendCase;
  Next next;

  Select(Case sendCase, Args... nextVals)
  : sendCase(sendCase), next({nextVals...}) {}

  Result<void, SelectErrors> step() {
    auto res = sendCase.attempt();
    if (res) {
      return {};
    }
    return next.step();
  }

  void operator()() {
    while (!step()) {
      std::this_thread::yield();
    }
  }
};

In addition to our step, we have an operator overload to make our select callable. This operator overload is simply a loop that keeps attempting from that select onwards until we have a success. Each failure we yield the thread so we're not hogging the CPU constantly. We have the operator overload at every step of the select since we have no way to tell which step is the first one at this level. That's okay though, since we'll just end up calling the first level in our outer code anyways.

Now on to receiving messages.

Select receives

The code is going to look almost identical, with the only difference being a few names. Which poses the question - why do we specialize on the type of the case rather than just use a generic type since it's all the same code structure anyways? The answer is simple: at some point we're going to add timeouts, and those aren't going to work the same way as sends and receives. And since that's our very next feature, there's no point in refactoring code until we write it and see what's actually refactorable. Until then, we're just going to duplicate the code.

Here's our receive handler:

template<typename T, size_t Capacity, typename Callback, typename ...Args>
struct Select<ReceiveCase<T, Capacity, Callback>, Args...> {
  using Case = ReceiveCase<T, Capacity, Callback>;
  using Next = Select<Args...>;
  Case receiveCase;
  Next next;

  Select(Case receiveCase, Args... nextVals)
      : receiveCase(receiveCase), next({nextVals...}) {}

  Result<void, SelectErrors> step() {
    auto res = receiveCase.attempt();
    if (res) {
      return {};
    }
    return next.step();
  }
  
  void operator()() {
    while (!step()) {
      std::this_thread::yield();
    }
  }
};

Ending a select

We've gotten our cases handled so far. Now we just need to add our terminating select. Even though our last select isn't going to do anything special, we still need to make sure we have the same function signatures. Including our operator overload (just in case someone creates a blank select of all things). Here's our ending select:

template<>
struct Select<> {
  Result<void, SelectErrors> step() { return error(SelectErrors::NOT_READY_YET); }
  void operator()() {}
};

Almost done! We're just going to add a convenience wrapper method to give us type deductions and to automatically call our select statement. Here it is:

template<typename ...Args>
void select(Args... args) {
  Select<Args...>{args...}();
}

Using the select

Now let's see what our developer experience is like! Here's a sample program using the select. In fact, its a C++ reproduction of the example Go program I showed earlier!

int main() {
  Channel<int, 1> c;
  Channel<int, 1> quit;

  auto t1 = std::thread([&]{
    int x = 1;
    bool done = false;
    while (!done) {
      // our select statement
      select(
          send_case(c, x, [&](const auto&){
            x *= x + 1;
          }),
          receive_case(quit, [&](const Result<int, ChannelBlockError>& v){
            auto val = v.get_value();
            std::cout << "Ending with " << val << "\n";
            done = true;
          })
      );
    }
  });

  for (int i = 0; i < 4; ++i) {
    std::cout << c.receive().get_value() << "\n";
  }

  quit.send(13);

  t1.join();
  return 0;
}

Whew! That's a long post!

Fortunately, this post lays a lot of the groundwork for the rest of the series. The next post will be shorter as well. Up next we're going to add a feature to our select statement which Go is lacking - timeouts. I cover the details in Building Channels in C++: Part 6 - Adding timeouts.