What this limit basically means is that if a component triggers more than 20 channels in one dispatch cycle (the simplest case being a single port that has more than 20 outbound connections), some will be lost.
I could probably figure out a fix for this, but I'm not sure what the best way would be. The two fixes I see right now are:
resize the RClist to have at least as many entries as a component has channels. If this could be done in the dispatch thread, it would not affect the realtime-ness of the component itself.
have a "dispatcher pool" and create a new dispatcher every time 20 channels have been assigned to one. Then get dispatchers back to the pool once they're empty.
I would personally favor (2) as it would be in line with the ability to explicitly choose a dispatcher at connection time, a pet feature of mine (thus allowing to create connection domains and isolate connections to each other - as e.g. GUI vs. in-robot or wifi vs. wired)
For reference:
https://github.com/orocos-toolchain/rtt/blob/master/rtt/transports/corba/CorbaDispatcher.hpp#L74
What this limit basically means is that if a component triggers more than 20 channels in one dispatch cycle (the simplest case being a single port that has more than 20 outbound connections), some will be lost.
I could probably figure out a fix for this, but I'm not sure what the best way would be. The two fixes I see right now are:
I would personally favor (2) as it would be in line with the ability to explicitly choose a dispatcher at connection time, a pet feature of mine (thus allowing to create connection domains and isolate connections to each other - as e.g. GUI vs. in-robot or wifi vs. wired)