Using coroutines as pluggable drivers of the graph

[knoepfel]

With art, any input source must emit one "message" at a time in a way that is consistent with the run-subrun-event hierarchy. Doing this correctly requires maintaining a decent amount of state, which can be cumbersome. With C++20 coroutines, I believe this can be substantially simplified.

For example, consider a simple run-subrun-spill hierarchy. It is conceivable that a user could create the following driver as a plugin:

std::generator<data_product_set_id> drive() 
{
  // Hard-code numbers for now, but they could be taken from an input file.
  unsigned int const num_runs = 2;
  unsigned int const num_subruns = 2;
  unsigned int const num_spills = 3;

  for (unsigned int r : std::views::iota(0u, num_runs)) {
    co_yield data_product_set_id{{r}};
    for (unsigned int sr : std::views::iota(0u, num_subruns)) {
      co_yield data_product_set_id{{r, sr}};
      for (unsigned int spill : std::views::iota(0u, num_spills)) {
        co_yield data_product_set_id{{r, sr, spill}};
      }
    }
  }
}

which would instruct the framework to process 2 runs, each with 2 subruns, with each subrun containing 3 spills. The framework code is then simple:

  for (auto const& id : drive())
    // Do what you want ...
    std::cout << id << '\n';

For working example, see here.

This approach could be helpful as we consider supporting the invocation of algorithms with data products from different hierarchies. We may want generators that return multiple data-product set IDs from different hierarchies.

[knoepfel]

Right now, oneTBB's support for coroutines is uncertain. Mike Voss has suggested oneTBB's resumable tasks could provide a similar interface for users while working directly with the oneTBB thread pool.

[knoepfel]

See issue #42.