Make message_passing public#130
Conversation
NEOatNHNG
requested review from
LittleHuba,
castler and
hoe-jo
as code owners
LittleHuba
added
the
import-started-do-not-modify
|
Closing this, as visibility was extended appropriately for other S-CORE modules to access the concrete targets. |
|
We have other use cases in infrastructure components apart from logging where we would like to re-use the message passing. I mean it is OK if we don't want S-CORE applications to use message passing directly, but other infrastructure components should be fine. Similar argument could be made for shared_memory from baselibs. We also don't want applications to use that directly but we don't limit the visibility there either. Most current example is the someip gateway where @lurtz is working on a bridge implementation which would also need to access message_passing. But we have also ETAS-internal use cases for this. @mishraajitesh |
LittleHuba
removed
the
import-started-do-not-modify
|
@NEOatNHNG could you please give some insight into the ETAS-internal use cases? |
Other infrastructure components such as the SOME/IP Gateway or the diagnostics stack may re-use it for their internal communication needs.
NEOatNHNG
force-pushed
the
make-message_passing-public
branch
from
86f5f40 to
251e701
Compare
NEOatNHNG
changed the title
castler
left a comment
castler
left a comment
There was a problem hiding this comment.
So we are not ready yet to give full advice (in written statement) when to use message passing and when to use LoLa.
In short:
If you need 1:N communication - you should use mw::com.
If you transfer bigger data (then you need zero-copy) - you should use mw::com
If you have only 1:1 communication and small data -> use message_passing.
When you could not change the visibility of the QNX dispatch target, we could merge this.
| visibility = [ | ||
| "//score/mw/com/impl:__subpackages__", | ||
| "@score_logging//score/datarouter:__subpackages__", | ||
| "@score_logging//score/mw/log/detail/data_router:__subpackages__", | ||
| ], |
There was a problem hiding this comment.
A user should just depend on //score/message_passing, not on //score/message_passing:message_passing_qnx_dispatch
Could you remove this part of the changset please?
There was a problem hiding this comment.
Thank you for the hint. Previously message_passing was an alias target that is why previously the extended visibility was also needed here. I have reduced it now.
Co-authored-by: Copilot <copilot@github.com>
3 participants
Other infrastructure components (also external to S-CORE) such as the SOME/IP Gateway or the diagnostics stack may re-use it for their internal communication needs.
Apart from the reduced implementation and resource overhead for infrastructure components, it is also beneficial to use message_passing instead of trying to build on top of mw::com to lessen the amount of configuration the integrators have to write in order to make those infrastructure components work. Otherwise they have to configure the infrastructure component and in addition also provide an mw::com configuration for the service instances used internally in the infrastructure component. This is error prone and provides negligible additional value.