Reasons:
- DeviceMaster::_node_map does not need to be shared among instances,
because there is at most 1 instance per Flavor and different Flavors
have non-intersecting device paths.
- Keeping it static would also require a static lock
- DeviceMaster::_node_map was not locked at all when used from
uORB::Manager
So this fixes two synchronization issues:
- Different DeviceMaster objects could access the same static data in
parallel
- getDeviceNode() called from uORB::Manager did not use any locking at all
This has the following benefits:
- Manager can ensure that there is at most one instance of DeviceMaster
per Flavor
- The Manager needs access to (static) data of DeviceMaster already.
This will make it easier to access this data in a non-static way, and
does not introduce new dependencies.
If enabled, orb reads a rules file (./rootfs/orb_publisher.rules) on
startup. This can contain rules about which module is allowed to publish
which topic. It is completely transparent, so a publisher does not know
if he's not allowed to publish, and publications will look as if they
succeeded.
To test, add
#define ORB_USE_PUBLISHER_RULES
to uORBManager.hpp
This adds two uORB API calls:
- orb_advertise_queue
- orb_advertise_multi_queue
Both add a queue_size parameter to define a maximum number of buffered
item. The existing orb calls use all a queue size of one and thus their
behavior is unchanged. If a writer publishes too fast, the oldest elements
from the queue are silently dropped.
The returned timestamp is always the one from the latest message in the
queue.
Queue size can be set via ioctl during advertisement phase. After that it
cannot be changed anymore.
This fixes a race condition: uORB::Manager::get_instance() is used in a
multi-thread context, but the singleton initialization was not thread-safe.
Further, this avoids having to check for nullptr every time the singleton
is accessed.
uORB::Manager::initialize() is called when uorb is started. No one else
accesses the singleton before that point, because it is only used in the
orb_* methods, and in muorb. Both require uorb to be started already when
they are used.
This is necessary when using multiple instances of a topic. However it does
not free the underlying resources, as it is assumed they will be used again
at a later point.
This fixes the previously introduced unit test. It fixes the case where
orb_subscribe_multi is called multiple times with different instances,
and no publisher advertised the topic yet. In this case all subscribers
got the same instance 0.
