Does eCAL support inner-process communication already?

[chengguizi]

I am working with eCAL 5.11.2 in C++, using Cmake.

Currently I can't get subscriber and publisher of the same topic to work simultaneously, as the first try.

I then tired to change use_inproc from ecal.ini. The default was 0, and I tried 1 or 2, it didn't work.

I then found this example

https://github.com/eclipse-ecal/ecal/blob/master/samples/cpp/performance/pubsub_throughput/src/pubsub_throughput.cpp

It points me to an API eCAL::Util::EnableLoopback(true);

Now it works. May I know what is happening here?

1. Why is eCAL::Util::EnableLoopback(true); needed? What does it do?
2. If the above API is to enable in process comm, what about use_inproc?

Thanks!

[FlorianReimold]

tl;dr: If you want your process to receive data from publishers from the same process, just keep the transport layers in their default configuration, but call eCAL::Util::EnableLoopback(true); once to enable Loopback.

---

1. Why is eCAL::Util::EnableLoopback(true); needed? What does it do?

EnableLoopback enables an eCAL Process to also receive data that had been sent by a publisher from the same process. How the data has been sent is not important for that (can be SHM, UDP, TCP, innerprocess). It's not like eCAL would not be able to receive the data otherwise, but it actively ignores data coming from its own process.

With eCAL::Util::EnableLoopback(true); you tell eCAL not to ignore that data anymore.

So why does it behave like that? Because receiving the data that you sent yourself is undesired for some people.

Is there any downside when enabling Loopback? No. If you want to receive the data you sent in your own process, just enable it and be happy.

2. If the above API is to enable in process comm, what about use_inproc?

The inproc transport layer is a transport layer that can only transport data inside its own process.

Is there a reason to use it without enabling loopback? No, that doesn't make sense. eCAL will not warn you about that configuration, but you are then telling it to "Only send data to your own process, but ignore everything that comes from your own process!".

Are there advantages of inproc compared to SHM? Not sure, maybe @rex-schilasky can comment on that 😀

[chengguizi]

Thanks for the answer! Yes would love to know the inside difference of inproc and SHM, so to know when to use what

[rex-schilasky]

The logic of inproc transport layer is that a publisher send call will executed all subscriber data callback in the same (publisher send call) thread. This is for sure quite fast (no copy needed here) but it couples the execution of the publisher send thread to the processing of the subscriber callback function. So very often the overall performance will decrease because you force a single threaded execution here.

If you switch on Loopback (as described by Florian) an inner process publisher is connected to inner process subscribers via memory file and they can act decoupled in a parallel manner.

A second aspect is .. if you have let's say one subscriber in the same node and at least one external subscriber (can be another node, the eCAL recorder or an eCAL monitor live data view) then anyway a memory file needs to be opened and maintained and you will not get any performance adds by using the inproc layer in parallel.

Hope that helps :-)

[chengguizi]

The second aspect explanation is great. Thanks, now I got it, sufficient insight. I will not use inproc then, as I do have a mix of intra and inter process subscribers.