lf-lang / reactor-cpp Goto Github PK

@zekailin00 found that when he attempts to interrupt the execution of his DeepRacer controller that uses the Cpp target, the program just keeps on running. Both Ctrl + C and Ctrl + D are ignored, and Ctrl + Z lets the program end abruptly (sometimes triggering a segfault). It is important to free up resources at the end of execution, or else things like GPIO pins become inaccessible during subsequent runs of the program, making debugging very onerous. Can we respond to Ctrl + C by initiating the shutdown sequence, like we're doing in reactor-c?

This might be related to lf-lang/lingua-franca#748

The LF code generator now requires C++20. Thus we can also upgrade the C++ version in this repo.

So far, multiports were implemented as plain vectors of ports. #24 introduces a new MultiPort class to organize ports in a smarter way. This is mostly motivated by an optimazation for sparse communication. In the discussion of #24 it became clear that both the old and the new solution allow user code to modify the multiport. For instance users could add or remove ports. Ideally we can use the new dedicated Multiport class to restrict user access and allow only safe operations.

In lf-lang/lingua-franca#1321, @petervdonovan pointed out that the following program fails to execute:

target Cpp

reactor ReactorWithMultiport {
    input[3] in: int

    reaction(in) {=
        for (auto i = 0; i < in.size(); i++) {
            if (in[i].is_present()) {
                std::cout << "received input at port " << i << std::endl;
            }
        }
    =}
}

reactor MultiportSplitter {
    output[3] out: int

    input in0: int
    input in1: int
    input in2: int

    in0, in1, in2 -> out
}

main reactor IndexIntoMultiportInput {
    splitter = new MultiportSplitter()
    receiver = new ReactorWithMultiport()

    splitter.out -> receiver.in

    reaction(startup) -> splitter.in1 {=
        splitter.in1.set(42);
    =}
}

The problem is located here, as there is no case for directly connecting an input to an output of the same reactor.

chrono is nice but also pretty awkward to use. We should aim at providing useful shortcuts. For instance, it would be nice to wrap cast operations and provide functions like to_seconds for casting durations.

To match the naming convention in target parameters, the command-line option for Cpp generated programs should be changed from -t and --threads to -w and --workers.

LF programs produce an assertion error as the current implementation of sync_shutdown assumes that it is called only once. Also, if multiple reactions call sync_shutdown, this could happen from multiple threads. Thus we need a thread safe implementation.

Currently, all reactor elements register a pointer to themselves at the containing reactor. When a ReactorElement is moved, this pointer stored at the containing reactor needs to be updated. This is currently not the case and leads to segfaults if the move constructor is used.

This is closely related to #3. Since the initial design of this runtime, some terminology has changed or we have developed better definitions of certain terms. In the core APIs, many terms should be updated. For instance, BaseAction should better be named BaseTrigger. Also, dependencies and antidependencies of reactions are better named sources and effects.

We want to catch any references to undeclared dependencies at compile time, not at run time. Dependencies could be data dependent and remain hidden for a long time if they are only caught at run time.

clang-tidy in LLVM 17 reports several issues. Those do not appear yet in CI as it uses an older version of LLVM.

Since the original design of the reactor-cpp runtime, some terminology has changed. For instance, we use "tag" to refer to the time stamp of an event (instead of logical time). Also the APIs used to access physical time, logical time, and tags have changed in C and Rust even introduces another API (I think). We should revisit the C++ APIs and bring them up to speed with the other targets.