Add a test to ensure the report_stats hook is actually called internally

[doctorlai-msrc]

The report_stats hook is internally called at some interval at jbpf_perf.c This PR adds a test to make sure it actually calls it.

[xfoukas]

Couldn't this test fail due to timing issues? What if the output thread is called right before the maintenance thread is called? Wouldn't io_channel_check_output() fail in this case although everything might be working fine?

[doctorlai-msrc]

We use sem_post(lcm_ipc_sem) to make sure the codelet is loaded only after maintenance thread is created. By default, a dummy output_handler is registered, before io_channel_check_output is registered.

I've ran the test 500 times, all passing.

[xfoukas]

But how can we guarantee that the maintenance thread is called? What if it is delayed for a long time (e.g., 1s), because it runs in a very resource constrained environment? Can we somehow make this test deterministic and avoid relying on the timer?

[doctorlai-msrc]

I don't think this is a problem. As the test use the semphore to ensure the maintenance thread is called see line 47 and 109.

[xfoukas]

The semaphore of lines 47 and 109 ensures that the test will only terminate when the data is received. But what if the maintenance thread is delayed for a long time as I described above? Doesn't that mean that when the io_channel_check_output() function is called, execution might go to line 50? This would lead to a test failure, not because there is any issue, but just because the maintenance thread was late to be called. Or am I missing something?

[doctorlai-msrc]

My understanding is that won't happen, as shown here and here the maintenance thread will be ready when _jbpf_handle_out_bufs is called. Correct me if I am wrong.

[xfoukas]

The thread will be ready, but there is no guarantee that it will be called before _jbpf_handle_out_bufs(). For example if both threads are running on the same CPU core and there is high contention, it could be that maintenance thread runs later than the io thread. As such, there could be scenarios where this test could fail simply due to high contention.

I would suggest to revisit this test, to somehow not rely on the synchronization order of the two threads.