Sometimes application overflow the children counters in the handle
flags. That leads to a bad crash, which is a bug, but it is also less
than ideal than one can't make a great many child entities.
With the way the bits are mapped, one can have 16k children of a single
entity and 4k concurrent calls on a single entity. This commit changes
that in two ways:
On 32-bit platforms, it shifts the division of bits, allowing up to
64k children and up to 1k concurrent calls on a single entity. It is
clearly still possible to run into the same bug, and even slightly
more likely to do so in progress with very many threads, but this
seems like a minor improvement nonetheless.
On 64-bit platforms, it changes the representation to an 64-bit
integer (it simply uses an uintptr_t), which gives plenty of room in
the field to substantially increase the width of the counters.
Just widening the counters is not an elegant solution, and 64-bits here
is a bit wasteful. Still, this should fix the problem at least in
practice.
I expect this will address the problems in #1679 and #2022 (although the latter doesn't quite seem to reach the required numbers, the symptom matches). As that all with ROS 2, it needs to be backported to the releases/0.10.x branch until Cyclone master/11.0-to-be and ROS 2 are friends again. (I expect it to be a trivial backport.)
Sometimes application overflow the children counters in the handle flags. That leads to a bad crash, which is a bug, but it is also less than ideal than one can't make a great many child entities.
With the way the bits are mapped, one can have 16k children of a single entity and 4k concurrent calls on a single entity. This commit changes that in two ways:
On 32-bit platforms, it shifts the division of bits, allowing up to 64k children and up to 1k concurrent calls on a single entity. It is clearly still possible to run into the same bug, and even slightly more likely to do so in progress with very many threads, but this seems like a minor improvement nonetheless.
On 64-bit platforms, it changes the representation to an 64-bit integer (it simply uses an uintptr_t), which gives plenty of room in the field to substantially increase the width of the counters.
Just widening the counters is not an elegant solution, and 64-bits here is a bit wasteful. Still, this should fix the problem at least in practice.
I expect this will address the problems in #1679 and #2022 (although the latter doesn't quite seem to reach the required numbers, the symptom matches). As that all with ROS 2, it needs to be backported to the
releases/0.10.x
branch until Cyclone master/11.0-to-be and ROS 2 are friends again. (I expect it to be a trivial backport.)