2024 06 25 Eclipse iceoryx developer meetup

Eclipse iceoryx developer meetup to discuss #2193 and #325

Date: 2024/06/25

Time: 17:00 CET

Link: https://app.element.io/jitsi.html#conferenceDomain=meet.element.io&conferenceId=JitsiVtfrqukadefbqiqfxryxabai&userId=&roomId=!AooDAAwkyNWwkMElpt%3Agitter.im&roomName=eclipse%2Ficeoryx&startWithAudioMuted=true&startWithVideoMuted=true&language=en

1.1 The keep alive thread does not wake up after the system time changes

the thread is waiting in a semaphore timed_wait call
timed_wait requires the CLOCK_REALTIME which is affected by changes in the local time
additionally the heartbeat is send as timestamp
- the timestamp uses the monotonic clock
- jumps into the future can still happen with the monotonic clock
- when RouDi checks for the last heartbeat, it might have a timestamp after a jump which is too far into the future compared to the heartbeat timestamp

1.2 There is a mutex to guard adding and removing subscriber queues to the publisher

the mutex also needs to be locked when the publisher accesses the subscriber queues for publishing
this is quite fast since there is no contention unless subscriber are added or removed from the publisher
nevertheless, there is a small window in which the application could terminate abnormally and leave a locked mutex behind
this usually only happens on either:
- a crash -> can be prevented on the application side by e.g. not running threads in parallel when publishing smaples
- not handling signals which leads to not running the destructors -> can be prevented by handling signals
- sending SIGKILL -> unfortunately this is also done by RouDi when monitoring in turned on and RouDi does not receive a heartbeat for some time; RouDi assumes the application is unresponsive and sends a SIGKILL in order to safely reclaim the resources

2.1 Possible solution for the monitoring issue

create a timer_create abstraction
use that abstraction in combination with a blocking semaphore wait instead of the semaphore timed_wait
use a counter for the heartbeat instead of the timestamp
- add a mechanism for RouDi to check when the counter does not change for some time to detect unresponsive applications

2.2 Possible solution for locking issue

revisit https://github.com/eclipse-iceoryx/iceoryx/pull/748
create a lock-free ring buffer for history
a workaround might be to skip the resource cleanup if the mutex is still locked and just leak the resource

3.1 ekxide might be contracted to fix the monitoring issue

3.2 Graham is looking into implementing the workaround

Mathias checks if the workaround is feasible and gives some hints on how to proceed