Map having no data source (a kernel has input only) could trigger segfault when execution starts.

[BamboWu]

Bug Description

If we build a map with no data source, meaning every kernel in the map has an input port, then a segmentation fault would be triggered upon execution.

Example To Reproduce the Bug

#include <iostream>
#include <raft>

class MasterKernel : public raft::kernel {

private:
    int dim;
    long chunk_size;
    bool waiting = false;
    uint8_t task_id;

public:
    MasterKernel(int _dim, long _chunk_size) :
        raft::kernel(), dim(_dim), chunk_size(_chunk_size) {
        std::cout << "master constructor\n";
        // Create ports
        input.addPort<uint8_t>("input");
        output.addPort<uint8_t>("output");
        task_id = 0;
    }

    virtual raft::kstatus run() {
        size_t numRead = 0;

        //std::cout << "Master waiting=" << waiting << std::endl;
        //if (waiting) {
        //    input["input"].recycle();
        //    waiting = false;
        //    if (2 == task_id) {
        //        return raft::stop;
        //    }
        //}

        // Get the number of points to operate on
        std::cout << "Master reads " << numRead << std::endl;

        // Push our output data
        output["output"].push<uint8_t>(task_id++);
        waiting = true;
        std::cout << "Master pushed\n";

        return raft::proceed;
    }
};


class LocalSearchKernel : public raft::kernel {
    int id;

public:
    LocalSearchKernel(int _id) : raft::kernel(), id(_id) {
        std::cout << "search constructor\n";
        // Create ports
        input.addPort<uint8_t>("input");
        output.addPort<uint8_t>("output");
    }
    virtual raft::kstatus run() {
        uint8_t &taskid( input["input"].peek<uint8_t>() );
        std::cout << __func__ << "(pop taskid=" << taskid << ")\n";
        output["output"].push<uint8_t>(taskid);
        input["input"].recycle();

        return raft::proceed;
    }
};

int main() {
  MasterKernel master(1, 10);
  LocalSearchKernel search(2);

  raft::map m;

  m += master >> search;
  m += search >> master;

  std::cout << "Executing map\n";
    // Execute the map
  m.exe< partition_dummy, pool_schedule, stdalloc, no_parallel >();

}

[jonathan-beard]

Waiting to fix this issue till I push the changes to the parser. The actual solution is a bit more involved given the shutdown process relies on knowing what the data source is, so...we need a way to infer which kernels should propagate the shutdown process. Any ideas on that? I've a few but the easiest ones seem a bit error prone:

• user indicates raft::stop, then the runtime propagates the shutdown signal - this could cause an issue if the programmer has feedback where they didn't expect which would cause deadlock.
• second approach involves a new kernel class that would indicate a "generate" or "source" kernel explicitly. I don't like this one at all given it's not easily backwards compatible.