Currently, enabling the iceoryx transport is an all-or-nothing matter. Either all topics use the iceoryx transport or none of them does.
In a larger system, this can be unnecessarily burdensome. A ROS system running on Cyclone, for example, may contain countless small publishers related to built-in ROS topics, services, or just small application-specific ROS topics. For those topics, iceoryx transport doesn't really have a large benefit. It is therefore needlessly onerous to conform to the various iceoryx restrictions (such as pre-allocated memory pools, peak number of outstanding loans, ...).
This PR adds a configuration mechanism to restrict use of iceoryx (or, more precisely, any PSMX mechanism) to individual named topics or to all but a few named topics. It thereby enables Cyclone users to enable iceoryx transport for those topics where shared-memory transport makes a real difference or to disable iceoryx for those topics where its restrictions are particularly onerous.
As a side-benefit, this PR also helps debugging bugs related to violations of the iceoryx preconditions. If, say, random segfaults are encountered in a project, topics can disable iceoryx one by one until the culprit is found.
The PR as contained right now is in working state, but a few polishes could still be applied (e.g., better testing). I'd like to agree on the general approach first before putting effort into tests, though.
Currently, enabling the iceoryx transport is an all-or-nothing matter. Either all topics use the iceoryx transport or none of them does.
In a larger system, this can be unnecessarily burdensome. A ROS system running on Cyclone, for example, may contain countless small publishers related to built-in ROS topics, services, or just small application-specific ROS topics. For those topics, iceoryx transport doesn't really have a large benefit. It is therefore needlessly onerous to conform to the various iceoryx restrictions (such as pre-allocated memory pools, peak number of outstanding loans, ...).
This PR adds a configuration mechanism to restrict use of iceoryx (or, more precisely, any PSMX mechanism) to individual named topics or to all but a few named topics. It thereby enables Cyclone users to enable iceoryx transport for those topics where shared-memory transport makes a real difference or to disable iceoryx for those topics where its restrictions are particularly onerous.
As a side-benefit, this PR also helps debugging bugs related to violations of the iceoryx preconditions. If, say, random segfaults are encountered in a project, topics can disable iceoryx one by one until the culprit is found.
The PR as contained right now is in working state, but a few polishes could still be applied (e.g., better testing). I'd like to agree on the general approach first before putting effort into tests, though.