-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the C runtime an independent library #4
Comments
You can make the main function part of the generated code, similar to C++ target. So you can rename
|
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);
} |
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.. |
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
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. |
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. |
@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.The text was updated successfully, but these errors were encountered: