search

langroodi / Adaptive-AUTOSAR

Adaptive Runtime AUTOSAR Linux Simulator
MIT License
399 stars 159 forks source link

Logsinks run in application context #16

Closed devendranaga closed 1 year ago

devendranaga commented 1 year ago

Describe the bug Logsinks run in application context. This means there can be two possible issues.

  1. logging of excessive messages leads to wait times in application / threads.
  2. contextual data (private data structure that is used to concat) is shared across threads and results in corrupted data.

To Reproduce This is a speculation for now.

Expected behavior I propose the following solution:

  1. implement logging server that takes the log data over a unix socket. This offloads the i/o latency on to the log server and application could either buffer or stream the log data to unix socket.
  2. use unique_locks and protect the common message buffer.
langroodi commented 1 year ago

logging of excessive messages leads to wait times in application / threads.

The statement above is out of the scope of the project. There are more parts within the project that can/should be optimized. However, due to the resource (e.g., time) limitation, they are not being considered in the development process. In despite of that, you are always welcomed to take a step and improve the mentioned part yourself and then it can be merged back to the project.

contextual data (private data structure that is used to concat) is shared across threads and results in corrupted data.

It is unclear which of the ara::log you are referring to, but as far as I can remember it is not explicitly required in the standard to make the log sink thread-safe. If that is the case, the one who is using/calling the log sink should take care of the cross-threading issue (which I checked quickly at applications and at the first glance I cannot find a possible cross-threading situation there). I also did not get your point with private data structure, because during my quick check I could not find a static class member among the logging framework and the logger which are a potential of causing a crossing thread issue (it is still possible I am missing it).

I can see console log sink as one of the log endpoints can be a possible issue. However, because the stream has been created at the logger and it will be dispatched to the log sink at once, it should not be the problem. I will close the issue for now until I have some materials that can reproduce the situation with and fix the issue accordingly.