Make the C runtime an independent library

[Soroosh129]

@cmnrd pointed out during today's weekly meeting that instead of copying the C runtime each time code is generated, we can provide a way to install the C runtime as a library and dynamically (or even statically) link to it. This would be somewhat similar to our current way of handling the RTI, where we ask the user to centrally install the RTI instead of generating it for each LF program.

I believe we need at least three versions of the C runtime library: unthreaded, threaded, federated.

The biggest obstacle to implementing this feature is the fact that the C runtime contains the int main() function.

[cmnrd]

You can make the main function part of the generated code, similar to C++ target. So you can rename main in the c runtime to something else, let's say foo. Then in the generated code you can do:

#include "reactor-c.h"
int main() {
  foo();
}

[Soroosh129]

Actually, now I remember that I had to already do that for the Python target. The main in the C runtime is very small:

int main(int argc, char* argv[]) {
    return lf_reactor_c_main(argc, argv);
}

[lhstrh]

I made a first step by transferring the C runtime to its own repo: https://github.com/lf-lang/reactor-c

Next, we need to include it as a sub module and make sure all the paths check out..

[petervdonovan]

I've said something like this before, but just so for our records and so that the discussion is in one place, I'll write it down here. I lean toward making the C runtime a separate library, but not installing it anywhere on the user's system nor trying to reuse it across compilations. This is because

• We have not had trouble with long compile times; furthermore, we should not anticipate having that problem because a) C is simple, so it compiles fast, and b) a core objective of the C runtime is for it to be lightweight. (Users who do not need that will presumably use the C++ or Rust runtimes.)
• Installing and linking to pre-installed libraries is a source of complexity in
  • the implementation (e.g., check for the required library, make sure it is installed, make sure we do not link against the wrong library, make sure the version of the library is up to date)
  • the user experience (e.g., to use federated LF, you must install the RTI and the federated decentralized version of the runtime)
• We define macros/add compile definitions to express some boolean variables that determine whether certain code is included, including
  • FEDERATED
  • FEDERATED_CENTRALIZED
  • FEDERATED_DECENTRALIZED
  • MODAL_REACTORS
  • LINGUA_FRANCA_TRACE
• We either already use or could in the future use compile definitions for numerical variables or variables that can take several values. These can obviously pose a much larger obstacle than the boolean variables:
  • LF_REACTION_GRAPH_BREADTH
  • LOG_LEVEL
  • NUMBER_OF_FEDERATES
  • WORKERS_NEEDED_FOR_FEDERATE
  • NUMBER_OF_WORKERS
  • SCHEDULER
  • several variables related to clock synchronization
• The use of such compile definitions may have small performance advantages in some cases in comparison to leaving values specified at runtime
• Compile definitions liberate us from having to generate code that specifies those values, and then pass the generated values around
• If I understand, we target use cases where people are willing to sacrifice flexibility and developer ergonomics in order to get highly specialized, highly optimized binaries.
• The Build-Type also affects the binary produced for the runtime

As we add more compile definitions, it is only going to get harder to make the C runtime a reusable independent library, so it would make sense for this decision to be final.

[Soroosh129]

I lean toward making the C runtime a separate library, but not installing it anywhere on the user's system nor trying to reuse it across compilations.

This sounds good to me. Abstractly, at least to me, the biggest driver for providing a standalone and installable reactor library would be so that it can be used on its own without Lingua Franca. As @edwardalee has said before, using a reactor library without Lingua Franca could allow unintended nondeterminism to creep in. This is even more true for a language like C, where it is easy to circumvent any safeguards reactor-c might have in place. So I agree that we shouldn't offer it as a standalone install.

On the other hand, aspiring to untangle reactor-c so that it can compile like a standalone library might result in a better, cleaner, and more maintainable design.