eclipse-iceoryx/iceoryx

Eclipse iceoryx™ - true zero-copy inter-process-communication

iceoryx's Issues

Mention colcon in install instructions

The current build instructions only cover the provided script to build and run tests.
For ROS2 devs, the iceoryx project can alternatively build natively with colcon. The install instructions shall reflect that.

Add teaser GIF and extend docu

Brief feature description

• Add teaser GIF
• Link "Eclipse iceoryx in 1000 words" from $ROOT/Readme.md
• Update PLANNED_FEATURES.md

Payload size not updated by allocateChunk(WithInfo)

Required information

Operating system:
Ubuntu 18.04 LTS

Compiler version:
GCC 7.4.0

Observed result or behaviour:
When allocating a chunk with allocateChunk or allocateChunkWithInfo using the dynamic payload option (useDynamicPayloadSizes = true) the ChunkInfo field m_payloadSize is initialized correctly by the first call. Subsequent calls of the same function with an increased payloadSize do not update the member variable.

Expected result or behaviour:
ChunkInfo::m_payloadSize should reflect the current payload size under all conditions.

Conditions where it occurred / Performed steps:

// publisher side
auto ci = m_publisher->allocateChunkWithInfo(42, true);
m_publisher->sendChunkWithInfo(ci);

auto ci = m_publisher->allocateChunkWithInfo(42+1, true);
m_publisher->sendChunkWithInfo(ci);

...

// subscriber side
const iox::mepoo::ChunkInfo* ci(nullptr);
while (m_subscriber->getChunkWithInfo(&ci))
{
  std::cout << ci->m_payloadSize << std::endl;
  m_subscriber->releaseChunkWithInfo(ci);
}

superfluous whitespaces throughout the codebase

there are a quite a few trailing whitespaces and mixes of tabs vs spaces.

Add relocatable pointers

New features:

• relocatable pointers
  (shared memory is mapped to an arbitrary location which requires pointers in apps to be location independent)
  • this feature enables applications to place their shared memory at different locations

Add parsable introspection output

Brief feature description

• Something like introspection –-stdout | log.txt would be nice to dump the introspection output in a file as line breaks make it hard to parse the introspection output

Detailed information

• Add PIDs of process to --process output
• Implement printer for cout
• Ncurses printer class

Memory abstraction, modularization of RouDi and fixes

New features:

• building blocks for shared memory abstraction (step 1)
• modularization of RouDi (step 1)

Fixes:

• mutex handling on QNX
• ease gateway development (added interface type to ServiceDescription)

Can't compile due to missing CPPTOML

Required information

Operating system:
OSX

Compiler version:
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.6.0
Thread model: posix

Observed result or behavior:
Can't compile workspace with colcon due to missing cpptoml dependency.

Expected result or behavior:
A clean colcon compilation where all dependencies are successfully resolved and I can use ROS2.

Conditions where it occurred / Performed steps:
colcon build --packages-up-to iceoryx_posh.

How to implement a gateway

Brief feature description

It would be really helpful, if there is an example gateway like there is an example avaialable for publisher and subscriber to see how a CaPro gateway needs to be implemented.

Detailed information

This could be a simple gateway to connect via TCP-IP or to connect two individual RouDis.

Remove asynchronous service discovery feature

Brief feature description

Remove asynchronous service discovery feature

Detailed information

iceoryx currently implements asynchronous service discovery feature (implemented with PoshRuntime::startFindService() & PoshRuntime::stopFindService() ), in addition to synchronous service discovery.
This feature belongs to higher layers, (which could implement this feature using iceoryx api)
Remove this for cleaning up iceoryx

CMqInterface unit tests are failing caused by unneeded move operations

Required information

Operating system:
Gentoo Linux, Kernel 5.5.6

Compiler version:
GCC 9.2 and clang 9.0.1

Observed result or behaviour:
These tests are failing:
CMqInterface_test.MqBase_MoveCTor
CMqInterface_test.MqBase_MoveOperator
CMqInterface_test.MqBase_TimedReceive
CMqInterface_test.MqInterfaceUser_MoveCTor
CMqInterface_test.MqInterfaceUser_MoveOperator
CMqInterface_test.MqInterfaceUser_TimedReceive
CMqInterface_test.MqInterfaceCreator_MoveCTor
CMqInterface_test.MqInterfaceCreator_MoveOperator
CMqInterface_test.MqInterfaceCreator_TimedReceive

Usage of github actions to build pull requests

Brief feature description

External Jenkins jobs are used to build and test the pull requests. Usage of github actions would be better,

Detailed information

With the actions, github provides the infrastructure do build the pull requests, this is much more transparent than using external Jenkins servers. The pull requests are also better documented then. In the rmw_iceoryx they were already introduced. We should also use them here.
e.g. see https://github.com/ros2/rmw_iceoryx/blob/master/.github/workflows/main.yml

Cleanup of codingrule warnings

This ticket adresses the cleanup of findings with our static code analysis to fulfil the codingrules.

Will be updated soon.

Docker environment for building and running iceoryx and examples.

Brief feature description

A Docker environment allows reproducible builds with controlled dependencies without polluting the user's host machine with extra packages needed for building and running iceoryx applications.

Acceptance criteria:

1. create a Docker image with a built iceoryx library, RouDi daemon, and examples.
2. provide an easy way to launch and use containers based on the above image.

A related follow-up may be publishing the Docker image to Docker Hub to allow users to run the prebuilt image directly, but this should be decided by the core iceoryx team.

Detailed information

Proposed content in tools/docker is:

• Dockerfile
• build/launch script(s)
• README.md
• other needed configuration files

Why pragma once instead of include guards?

#pragma once is indeed a nice feature, yet not part of the standard and shall not be used (for portability issues for example). Not to mention that standards like Autosar Guidelines for C++ 14 and Misra c++ 08 do not allow it.
Modules in C++ 20 will surely be nice, but it's adoption will take some time in the industry. Having pragma once here will definitely slow down the adoption of iceoryx.

Need for easy mempool configuration

Brief feature description

Motivated from ros2/rmw_iceoryx#5

Detailed information

The current mempool configuration is hardcoded in https://github.com/eclipse/iceoryx/blob/master/iceoryx_posh/source/mepoo/mepoo_config.cpp#L44-L54 and should be changed to be set dynamically on startup.

Remove const_cast wherever possible

Brief feature description:
Check the necessity of all occurring const_casts and remove them if possible.

Detailed information:
To check/improve const correctness in iceoryx we should take a look at all occurring const_casts and refactor them if possible.

Add performance example, introspection lib and fix timer and more

New features:

• performance example "iceperf"
• rename chunkInfo to chunkHeader
• remove internal port prefix and introduce port scope
• introduce introspection library
  • add size/capacity get methods for delivery FiFo
  • add port data in receiver info

Fixes:

• race in POSIX timer fixed

Support for n:m communciation (multiple senders on a topic / CaProID)

Brief feature description

Currently for each CaProID only one sender is allowed. This shall be extended to support m:n communication.

Detailed information

ROS2 is based on the DDS communication philosophy. In contrast to AUTOSAR, it is allowed that several publishers are writing to the same topic. This is currently not fully supported in iceoryx. For this feature the receiver ports must support multi-pusher queues.
To be more flexible for different communication patterns, we will have a bigger refactoring. Also the iceoryx public API will be affected

• chunk queue building block

• chunk distributor building block

• chunk sender building block

• chunk receiver building blocks

• publisher port

• subscriber port for single producer

• condition variable

• Integration of condition variable in existing building blocks

• MPMC queue and integration in variant queue + harmonization of queue interfaces and port interfaces

• subscriber port for multi producer

• adaptation of RouDi for managing new ports and condition variable

• adaptation of public API

• new examples and go live

compilation error in utils

Required information

Operating system:
Ubuntu 16.04.6 LTS
(as per ubiquity robotics image compiled on raspberryPi 3b)

Compiler version:
GCC 7.4.0 (for arm ->raspi)

Observed result or behaviour:
allocator.cpp:44:75: error: no matching function for call to ‘align(uintptr_t&, const uint64_t&)’
uintptr_t l_alignedPosition = cxx::align(l_currentAddress, f_alignment);
--> template class has only a shared parameter type for both parameters of cxx::align. Add a second template type or make second parameter (alignment) a static type e.g. uint64_t.

Expected result or behaviour:
Does compile.

Conditions where it occurred / Performed steps:
Using ubiquity robotics image compiled on raspberryPi 3b
additional to install instruction added GCC v7 as default.
(Compilation did finish after changing cxx::align 2nd parameter type (in helplets.hpp) to static type uint64_t.)

Basic Windows 10 support

Brief feature description

Having the possibility to use iceoryx on Windows 10

Detailed information

• Needed for ROS2 tier 1 support ROS2 Tiers

• Unit and integration tests, except timing tests, of the supported features need to run on Windows
  • remove define public private #529
  • all tests build and are green

The following features have to be implemented

• Implement and integrate named pipes for IPC in windows
• inter process capable mutex
• inter process capable semaphore
• use named ipc semaphore in named pipe

Reserved chunkinfo user payload header

Brief feature description

When sending a payload chunk via publishers sendChunk method a user can pass the payload memory pointer and it's size to transfer it with zero copy behavior to the subscribers side. If there is any additional content that needs to be transferred too (like counter, user timestamp, hash values ..) there is no option to apply this information additionally into the chunk header. So the only way to transport the payload data and some additional header information as single chunk is to do an extra memory copy in a new payload memory block before sending it as one chunk. So for this use case the amazing zero memory concept is broken.

Possible solution

Provide a reserved space in the ChunkInfo header to hold / transfer a user specific payload header that is not in the same linear memory like the payload data.

---

edited by @elBoberido

Progress Tracking

• Design Document
• Extend the current ChunkHeader and write test for the new functionality
• remove ChunkInfo and use the refactored ChunkHeader in the code base
• extend the API to access the new functionality
  • typed API
  • untyped API
  • C API
• restrict access to ChunkHeader members and hand out references instead of pointer
• documentation and examples
• cleanup
  • remove all TODOs
  • remove chunk_mock_dds.hpp and user chunk_mock.hpp instead
  • in order to reduce ambiguity don't use just payload but chunkPayload and userPayload. The chunkPayload consists of the customHeader/userHeader and userPayload

Can't use static initializers for subscribers due to deleted move semantics

This is more like a question than an issue, but why are the move semantics deleted for a subscriber?

https://github.com/eclipse/iceoryx/blob/e588ccbc8886aab208eca50f88c89dde09a0d137/iceoryx_posh/include/iceoryx_posh/popo/subscriber.hpp#L62-L64

That makes static initializers a bit complicated as the implicit RVO is disabled.

Cleanup or Remove ObjectPool

Brief feature description

The object pool is in a very early stage and should be refactored/cleaned up or it should be removed. At the moment it is used nowhere.

Steps

1. If ObjectPool is not needed - remove it. If needed, perform the rest of the steps
2. follow up every todo and fix it.
3. move implementation from header (hpp) into inline (inl) file
4. cleanup unit tests (small unit tests with one or two EXPECT_*) with an behavior driven approach.

iceoryx to cyclonedds gateway

Brief feature description

A gateway to bridge between iceoryx and systems using the cyclonedds stack.
This component handles the communication in the iceoryx -> dds direction.

Detailed information

Should allow for data published in iceoryx systems to be received remotely via DDS.
This component is a building towards achieving internode communication between iceoryx systems.

macOS support

Brief feature description

Having the possibility to use iceoryx on macOS

Detailed information

Needed for ROS2 tier 1 support
ROS2 Tiers

remove blinking warning in Roudi

The warning of Could not open file '/etc/iceoryx/roudi_config.toml'. is somewhat misleading as it doesn't give the user any more info about what's happening.

Not only does it (annoyingly) blink, the RouDi application runs perfectly fine.

If you look at the two warnings around that, I don't see why this warning has to be red and blinking:

2020-04-13 17:36:36.144 [ Info  ]: No config file provided. Using /etc/iceoryx/roudi_config.toml
Could not open file '/etc/iceoryx/roudi_config.toml'.
2020-04-13 17:36:36.144 [ Info  ]: No config file found at /etc/iceoryx/roudi_config.toml. Falling back to built-in config.

Compilation error with GCC 9.1.0

Operating system: Arch Linux

Compiler version: GCC 9.1.0

Observed result or behaviour: Software does not compile (./iceoryx_utils/cxx/variant.hpp:231 error: requested alignment is not an integer constant)

Expected result or behaviour: Software shall compile

Conditions where it occurred / Performed steps: run ./tools/iceoryx_build_test.sh

string with fixed but compile-time configurable capacity

Brief feature description

For a fine grained control of the size of strings in different parts of the project, a string with a fixed but compile-time configurable capacity is required. Furthermore, throwing exceptions or using heap is forbidden.

Detailed information

This can be achieved by integrating the new cxx::string which uses a template parameter for its capacity. It also provides a std::string compatible comparison which compares past the first '\0'.

Refactoring of logging

Brief feature description

There is no clear logging strategy. There is an iceoryx logger but it is not used everywhere. The internal logger should be used and if not in same places a clear strategy should be available when to not use it. Refactoring according to the strategy then

Capability to cleanup shared memory resources during process lifetime

Brief feature description

Capability to destroy single ports in the shared memory individually and not only all together when cleaning up the whole user process.

Detailed information

Today, when publishers and subscribers are destroyed, the shared memory resources are not cleaned up. This is done when the whole process is cleaned up, i.e. when the process is terminated.
For better supporting systems like ROS where publishers and subscribers can be flexibly created and destroyed within the process lifetime, iceoryx must be extended to allow destroying shared memory resources like ports individually.

Typos in documentation

Required information

Operating system: Ubuntu 18.04 LTS

Compiler version: GCC 7.4.0

Observed result or behaviour:

• Debian release link does not work
• Example links $ROOT/README.md broken (e.g. examples/icedelivery)
• Typo in $ROOT/README.md "Great that your still here"
• Typo in $ROOT/README.md "./tools/iceoryx_build - test.sh"
• Mention examples are built by script in $ROOT/iceoryx_examples/README.md

Expected result or behaviour: No wrong script names, links or typos

Conditions where it occurred / Performed steps: Github web GUI (Commit e5c23ea)

Reduce default memory consumption with config and mempools

Brief feature description

The current defaults for compile time configuration and mempools are quite high. Better have reasonable defaults and let people increase the values if needed

Detailed information

With the current default configuration we need ~200 MB for the internal data structures and the default memory pools have ~ 600 MB. This is a challenge on systems which only have some hundred MBs of RAM left. Beginners could be confused and get out of memory errors on RouDi startup. We support 4096 publishers and subscribers with the default config. Because of max size allocation with fixed size containers this blows up the memory. For most users a lower number is sufficient. The mempools can be easily configured with the config file now, so having the large default does not make sense IMHO

Failure in runnable creation

Required information

Operating system:
Ubuntu 18.04 LTS

Compiler version:
GCC 7.4.0

Observed result or behaviour:
When using iceoryx together with rmw_iceoryx, we get an invalid response when creating a runnable

Expected result or behaviour:
runnables can be created without error

Conditions where it occurred / Performed steps:
Use latest master from iceoryx and rmw_iceoryx

Minor RouDi cleanups

Brief feature description

• Leftovers from #70 and #78

Detailed information

• Deprecate old RouDi c'tors
• Take care of @todo in RouDi files

compile error with clang

Required information

Operating system:
Ubuntu 18.04 LTS

Compiler version:
clang 9

Observed result or behaviour:

• the TOML support doesn't work
• posh is not compiling
• the tests are not compiling

Expected result or behaviour:
compile iceoryx with clang 9

Conditions where it occurred / Performed steps:
complile iceoryx with clang 9

Memory abstraction and RouDi modularization step 2, fixed string improvements and other fixes

Brief feature description

Step 2 of the RouDi modularisation and shared memory abstraction

Detailed information

• building blocks for shared memory abstraction (step 2, followup of #59 )
• modularization of RouDi (step 2, followup of #59)
• building blocks for sender and receiver port refactoring
• fixed string improvements
• fix warnings signed/unsigned at numeric literals

Request/Response communication with iceoryx

Brief feature description

Besides publish/subscribe also request/response communication shall be supported

Detailed information

So far iceoryx only supports publish/subscribe. For frameworks like ROS2 also a request/response communication shall be supported (services in ROS2). The building blocks in posh can be re-used here, so start with client and server ports and then do the layers above

We will have the same layered architecture as for publishers and subscribers. With ChunkSender and ChunkReceiver common building blocks are reused but a Client and a Server will use one of each for the bidirectional data transfer with requests and responses.
This image is a simplified view that shows the class hierarchy and the public method names for the typed C++ API.

1. It will also have a zero-copy API, i.e. we can loan requests and take responses on the Client side and take requests and loan responses on the Server side.
2. Like a Publisher, a Server can offer() or stopOffere()
3. Similar to a Subscriber subscribe() and unsubscribe(), the Client can connect(), disconnect() and getConnectionState()
4. You can poll the Server for requests and the Client for responses or use a Waitset to wait for requests and responses

• 1. Design and interface implementation for ports

• 2. Implementation and unit tests for ports

• 3. Integration test for ports

  • including QueueFullPolicy tests with a real Client- and ServerPort

• 4. C API

  • client
  • request/response header
  • server
  • examples
  • (optional) add iceoryx_posh_types.hpp RPC related config stuff to config.h.
  • (optional) add missing functionality to chunk header

• 5. C++ API

  • typed C++ API
  • tests for typed C++ API
  • untyped C++ API
  • tests for untyped C++ API
  • send returns an expected instead of void

• 6. Integration in runtime and RouDi

  • Make ServerPort's findable via ServiceDiscovery

• 7. Common port queue policies

  • rename SubscriberTooSlowPolicy -> ConsumerTooSlowPolicy
    • alias for ConsumerTooSlowPolicy for easy migration to new API
    • rename WAIT_FOR_SUBSCRIBER -> WAIT_FOR_CONSUMER
    • add WAIT_FOR_SUBSCRIBER = WAIT_FOR_CONSUMER for migration purposes
  • rename QueueFullPolicy::BLOCK_PUBLISHER -> QueueFullPolicy::BLOCK_PRODUCER
    • add BLOCK_PUBLISHER = BLOCK_PRODUCER for migration purposes
  • decide if SubscriberTooSlowPolicy, WAIT_FOR_SUBSCRIBER and BLOCK_PUBLISHER should be deprecated

• 8. Integration test with clients, server and waitsets (user API level)

• 9. Example

Add introspection client

New feature

• Add introspection client for debugging
  • Command line app
  • Shows memory usage
  • Shows connected process
  • Shows ports

Subscriber doesn't receive the first data from publisher in icedelivery example.

Required information

Operating system:
Ubuntu 18.04 LTS

Compiler version:
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)

Observed result or behaviour:
While running example program(ice-publisher-xxx and ice-subscriber-xxx), subscriber doesn't receive the first data.

Expected result or behaviour:
If we run the subscriber first, and then run publisher, every data should be received by subscriber.

Conditions where it occurred / Performed steps:

• Run the RouDi frist
• Run ice-subscriber-xxx (ice-subscriber-simple or ice-subscriber-bare-metal)
• Then run ice-publisher-xxx (ice-publisher-simple or ice-publisher-bare-metal)
• The terminal of subscriber will show:

-> % ./ice-subscriber-simple
2020-03-12 18:14:48.445 [ Info  ]: Application registered management segment 0x7feb693f0000 with size 113308800 to id 1
2020-03-12 18:14:48.446 [ Info  ]: Application registered payload segment 0x7feb45c41000 with size 595259200 to id 2
Callback: 1
Callback: 2
Callback: 3
Callback: 4

• The terminal of publisher will show:

-> % ./ice-publisher-simple
2020-03-12 18:14:50.683 [ Info  ]: Application registered management segment 0x7f3cbd3f0000 with size 113308800 to id 1
2020-03-12 18:14:50.684 [ Info  ]: Application registered payload segment 0x7f3c99c41000 with size 595259200 to id 2
Sending: 0
Sending: 1
Sending: 2
Sending: 3
Sending: 4

• The data 0 is lost.

Tests on Raspberry Pi 4 failing

Required information

Operating system:
Raspbian Buster (32-Bit)
Linux armv7l GNU/Linux

Compiler version:
E.g. GCC 8.3.0

Observed result or behaviour:
Multiple Tests on Raspberry Pi 4 are failing.

Expected result or behaviour:
All tests are green

Conditions where it occurred / Performed steps:
checkout iceoryx master
execute "./tools/iceoryx_build_test.sh test"
ececute "build/utils/utils/utils_moduletests" manually

Test Logs:

iceoryx_posh:
[ RUN ] ShmCreatorDeathTest.AllocatingTooMuchMemoryLeadsToExitWithSIGBUS
/home/pi/dev/iceoryx/iceoryx_posh/test/integrationtests/test_shm_sigbus_handler.cpp:43: Failure
Death test: iox::runtime::SharedMemoryCreatoriox::roudi::MiddlewareShm sut(badconfig)
Result: failed to die.
Error msg:
[ DEATH ] Reserving 111604128 bytes in the shared memory [/iceoryx_mgmt]
[ DEATH ] [ Reserving shared memory successful ]
[ DEATH ] 2020-03-17 08:54:59.689 [ Info ]: Roudi registered management segment 0xffffffffb0121000 with size 111604128 to id 1
[ DEATH ] Reserving 107374188800 bytes in the shared memory [/pi]
[ DEATH ] [ Reserving shared memory successful ]
[ DEATH ] 2020-03-17 08:54:59.690 [ Info ]: Roudi registered payload segment 0xffffffffb6fe5000 with size 107374188800 to id 2
[ DEATH ]
Reserving 111597024 bytes in the shared memory [/iceoryx_mgmt]
[ Reserving shared memory successful ]
2020-03-17 08:55:00.066 [ Info ]: Roudi registered management segment 0xffffffffb0123000 with size 111597024 to id 1
Reserving 1088 bytes in the shared memory [/pi]
[ Reserving shared memory successful ]
2020-03-17 08:55:00.066 [ Info ]: Roudi registered payload segment 0xffffffffb6fe6000 with size 1088 to id 2
[ FAILED ] ShmCreatorDeathTest.AllocatingTooMuchMemoryLeadsToExitWithSIGBUS (750 ms)

iceoryx_utils:
[ RUN ] relativeptrtests/0.ConstrTests
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:127: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:143: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:152: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
[ FAILED ] relativeptrtests/0.ConstrTests, where TypeParam = unsigned char (2 ms)

[ RUN ] relativeptrtests/1.ConstrTests
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:127: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:143: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:152: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
[ FAILED ] relativeptrtests/1.ConstrTests, where TypeParam = signed char (1 ms)

[ RUN ] relativeptrtests/2.ConstrTests
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:127: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:143: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relative_pointer.cpp:152: Failure
Expected equality of these values:
rp.getId()
Which is: 2
1
[ FAILED ] relativeptrtests/2.ConstrTests, where TypeParam = double (1 ms)

[ RUN ] RelocatablePointer_test.relocation
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_relocatable_ptr.cpp:78: Failure
Expected equality of these values:
base2 - base1
Which is: -1024
BLOCK_SIZE
Which is: 1024
[ FAILED ] RelocatablePointer_test.relocation (1 ms)
[----------] 1 test from RelocatablePointer_test (1 ms total)

[ RUN ] Duration_test.divideDuration
/home/pi/dev/iceoryx/iceoryx_utils/test/moduletests/test_unit_duration.cpp:202: Failure
The difference between result.seconds() and 8.666666666666666 is 1.7763568394002505e-15, which exceeds doubleEpsilon, where
result.seconds() evaluates to 8.6666666666666679,
8.666666666666666 evaluates to 8.6666666666666661, and
doubleEpsilon evaluates to 2.2204460492503131e-16.
[ FAILED ] Duration_test.divideDuration (0 ms)

ASIL-D compliance

Is there any updates on ASIL-D compliance and how do you plan on getting there?
We are looking at using Iceoryx in a commercial product and would like to understand the roadmap for safety.

cyclonedds to iceoryx gateway

Brief feature description

A gateway to bridge between iceoryx and dds systems using the cyclonedds stack.
This component handles the communication in the dds -> iceoryx direction.

Detailed information

Should make data in published in a dds system (namely, available in the dds global data space (GDS)), visible to iceoryx systems.
Data published by iceoryx->dds gateway provided in #64 should appear as if the originated locally.

Support for data published to the GDS by third party applications is out of scope for the initial version.

Colliding filenames within .github folder

Required information

Operating system:
Any case insensitive filesystem

When checking out (on OSX):

warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  '.github/ISSUE_TEMPLATE/BUG_REPORT.md'
  '.github/ISSUE_TEMPLATE/bug_report.md'
  '.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md'
  '.github/ISSUE_TEMPLATE/feature_request.md'

Is that simply a typo or why are these files existing with different cases?

Introduce cxx::function_ref

Brief feature description

Introduce a light-weight alternative cxx::function_ref as std::function can use heap under certain conditions which does not meet the requirements for high-safety environments

Detailed information

cx::function_ref - a non-owning reference to a callable

Proposed features:

• Not use heap
• No exceptions
• Stateful lambda support
• C++11 support

Loosely based on this proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0792r5.html

lock free mpmc queue

Brief feature description

Create a lock-free multi producer multi consumer queue to be used in multicast scenarios (as in e.g. ROS) and for internal control flow.

Detailed information

Properties:

1. lock-free and hence thread-safe
2. usable by an arbitrary number of multiple producers and consumers concurrently
3. no dynamic memory for safety reasons (uses its own memory buffer, determined at compile time, later configured during initialization)
4. robust -when an application terminates unexpectedly while using the queue
   the middleware daemon has to stay operational
5. suited to be placed in shared memory
6. low performance overhead when there is little contention

Write ReadMe for Iceoryx Utils

Brief feature description

Readme introducing the constructs which are used in iceoryx

Detailed information

If someone implements new features they have to know which building blocks are already available and can be used. Additionally, we should explain our best practices.

Iceoryx shared memory between docker containers (and host system)

Brief feature description

To communicate between docker containers and their applications using shared memory, RouDi and /dev/shm/-locations need to be shared across these containers. This would allow proper separation of applications while using highly performant shared memory between them.

Detailed information

My initial try was to mount:

• /dev/shm/iceoryx_mgmt
• /dev/shm/[group-name]
• and var/run/roudi.pid

While starting RouDi on the host system, in the docker container I could see the mounted locations but of course the pid mentioned in var/run/roudi.pid is not correct from perspective of the non-RouDi container. I wonder whether this is the reason for the iceoryx application to not find RouDi? Maybe you have an Idea where to look at?

Support multiple receivers on a topic with the same message queue name (iox::runtime::PoshRuntime::getInstance("/xxx"))?

I get the following error message, when I try to start an example subscriber multiple times:

$ ./build/iceoryx_examples/icedelivery/ice-subscriber-bare-metal 
Receiving: 1249
Receiving: 1250
Receiving: 1251

$ ./build/iceoryx_examples/icedelivery/ice-subscriber-bare-metal
2020-01-22 00:45:03.179 [Warning]: MQ still there, doing an unlink of /subscriber-bare-metal
2020-01-22 00:45:33.183 [ Error ]: ICEORYX error! MQ_INTERFACE__REG_ACK_NO_RESPONSE
ice-subscriber-bare-metal: /home/wenwen/tools/iceoryx-rs/iceoryx/iceoryx_utils/source/error_handling/error_handling.cpp:53: static void iox::ErrorHandler::ReactOnErrorLevel(iox::ErrorLevel, const char*): Assertion `false' failed.
fish: “./build/iceoryx_examples/icedel…” terminated by signal SIGABRT (Abort)

Is it possible to support multiple receivers on a topic with the same message queue name? Or it is not allowed because of some good reasons? Better error message for such "misuse" would be very nice.

Copy and paste typo in a_typed_api.hpp

Required information

Operating system:
Ubuntu 18.04 LTS

Compiler version:
GCC 7.4.0

Observed result or behaviour:
Copy and paste issue in a_typed_api.hpp ?

https://github.com/eclipse/iceoryx/blob/ea4018918f3752f8c9ee5e48fb08626bbfc5a39e/iceoryx_examples/icedelivery/a_typed_api.hpp#L123

Shouldn't it be TopicType instead CounterTopic ?