Is it possible to lose some of the memory?

[enesemre0106]

First of all, thank you for your efforts for this open source library.

As a Turkish company we are looking for a reliable Shared Memory based IPC communication library for our application with heavy data transfer. Iceoryx is the best option so far but there are some questions that I want to ask you.

• Lets say that either publisher or subscriber took a memory by loan() or take(). After that, they could not do the corresponding action: release() and publish(). Simply, gathered memories are lost because of the some middle step errors. My question is that are there any reset or some other recovery mechanisms for these situations?

When I investigated your codes, I could not see anything for those types of situation but if I am wrong and there are some precautions or solutions for these situations in the codes, please pardon my juniority :D

Thanks for your time and concern.

[elBoberido]

Depending on the typed or untyped API, there is a different behavior.

With the typed API you get a Sample<T> and the destructor of the sample will release the memory chunk.

With the untyped API it is the responsibility of the developer to return the memory chunk to the middleware, either by publish() or release(). It's similar to malloc()/free().

In case the application dies, the RouDi daemon will notice this after a few seconds and release all the memory chunks. There is one highly improbable scenario where one memory chunk could be lost when the application dies at the wrong moment but that should virtually never happen.

Does this answer your question?

[enesemre0106]

We are planning to use untyped API. I got the main idea but there are still some questions in my mind.

• How daemon decides whether publisher and subscriber are still crashed or not? With some heartbeat&timeout system or are there some handshake mechanism between daemon and publishers/subscribers?
• If the above questions answer is timeout with heartbeat, then can parameter of timeout be editable by users?
• Lets say that daemon thinks that subscriber is crashed and cleans the memory but subscriber is still processing the memory, what happens in this case? How the system prevents the possible segment fault error caused by multiple access to same shared memory address by different codes working with different virtual tables?

[elfenpiff]

We are planning to use untyped API.

We recommend to use the typed API if it is possible for you since then you take advantage of automatic lifetimes etc. and as the past experience has shown you will most likely hunt fewer bugs during your development.

Why would you like to use the untyped API? If you would like to send different data types via one service it may as some benefits. I am asking since I would like to know if we missed some kind of feature/use case in the typed API which is hindering you to accomplish your goal and maybe we can fix this quickly.

How daemon decides whether publisher and subscriber are still crashed or not?

An application has to send a heartbeat every 500ms after a runtime instance was created successfully. If our central broker RouDi does not receive a heartbeat for 2 seconds it assumes that the application has crashed, kills the application via TERM and later KILL signal (if term was not successful). Even if your application is a heavy number cruncher it should never effect the heartbeat since it is handled in a separate background thread which you created by creating the runtime instance.

If the above questions answer is timeout with heartbeat, then can parameter of timeout be editable by users?

Not yet but we can add this parameter quickly to iceoryx_posh_types.hpp then it is possible for you to configure this at compile time. But when you change the parameter you have to recompile iceoryx and all you rapplications depending on iceoryx with the updated parameter.

Lets say that daemon thinks that subscriber is crashed and cleans the memory but subscriber is still processing the memory, what happens in this case?

The daemon first sends a SIGTERM signal to the application, when the application is not terminated after a specific time the daemon will kill it with a SIGKILL signal.

How the system prevents the possible segment fault error caused by multiple access to same shared memory address by different codes working with different virtual tables?

This is a very good question with a complex answer. Here some short statements.

• If you are referring to C++ vtables, there are none used in the classes stored in the shared memory segment. We use a data driven design to still allow polymorphic designs.
• We have relocatable pointers which solve the issue of pointers pointing to process local addresses in the shared memory segment. So that every process can map the shared memory to any arbitrary base address.
• With lock free algorithms we solve the issue that one process is able to block another process indefinitely. Can happen when one process acquires a mutex and segfauts and another process is trying to acquire that mutex.

[elBoberido]

Just a small addendum, there is still one last lock in the communication. We plan to also remove that one but there is a small window when samples are published where one application could crash and affect others.