Report runtime settings in all target runtimes

[lhstrh]

@cmnrd raised the following question:

How to test the workers and threading properties?

When in debug mode, all runtime implementations could print a summary of their settings, including how many workers it uses. I think it would be quite useful to standardize what this summary would look like. Once we spec this out, we should implement it in all targets and have tests that simply check the output.

[cmnrd]

I think this is one side of the coin. However, the initial concern of my comment is another. If we use test configurators to set threading and workers for every test, then how can we test if the target properties threading and workers actually work as they should? We would need a test category where we don't overwrite these values and use what is specified in the target properties of the test LF programs.

[lhstrh]

But what would the test be? The numbers of workers does not affect program output.

[cmnrd]

Whether the target property workers: 42 indeed sets the number of workers to 42. It would be mostly testing our code generators. If we always configure workers and threading in the test setup, then we don't know if setting workers and threading via target properties works.

We have precedence for this in the Rust target. While the code generator was able to deal with the threads set in the target config, the threads property was not enabled for Rust.

[lhstrh]

How do we know that the specified number of workers is truly set? Wouldn't inspecting the config that the runtime reports be sufficient? Is there any other way to check?

[Soroosh129]

On Linux, you could externally verify how many threads a process is using (via ps or htop).

But I think what @cmnrd wants could be achieved via a test like this (at least in the C target):

target C { workers: 16 };
main reactor {
    reaction(startup) {=
        if (NUMBER_OF_WORKERS != 16) {
            error_print_and_exit("Expected to have 16 workers");
        }
    =}
}

[lhstrh]

@Soroosh129 your suggestion is implementable now and does not require any standardization across targets or parsing program output like this issue proposes. I still think the functionality described in this issue would be useful, but I suggest we decouple it from the issue of testing the workers property, and implement the test you proposed as an immediate fix to #993.

[cmnrd]

A test like Soroush proposes would also be easy to implement in C++. However, given our current test setup, this test will fail since the configurators will invoke lfc with workers=1 for single-threaded tests and with workers=4 for concurrent tests. There is currently no way to use the workers property as specified in the test. This is the point I was trying to make ;)

[lhstrh]

But I already added a test for C++? See Workers.LF

[cmnrd]

Oh, ok. So you removed the configurator that sets the number of workers. Looks like a viable solution to me :)

[Soroosh129]

Is there anything other than the number of workers that would be useful to print out?

I added the following to the C threaded runtime:

info_print("---- Using %d workers.", _lf_number_of_workers);