# Libcanard calling canardRxAccept handler in O(1) time

**URL:** <https://forum.opencyphal.org/t/libcanard-calling-canardrxaccept-handler-in-o-1-time/1257>\
**Category:** Libcanard\
**Created:** [May 11, 2021, 8:08pm UTC](https://forum.opencyphal.org/t/libcanard-calling-canardrxaccept-handler-in-o-1-time/1257 "2021-05-11T20:08:33Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\
**Post date:** [May 11, 2021, 8:08pm UTC](https://forum.opencyphal.org/t/libcanard-calling-canardrxaccept-handler-in-o-1-time/1257/1 "2021-05-11T20:08:33Z")

</div>

On a system implementing many `CanardRxSubscription` instances you will end up with a big list to iterate trough when receiving a frame from `canardRxAccept` yielding a processing time of O(n).

Pavel made a proposal to change `canardRxAccept()` by adding a pointer to the associated `CanardRxSession` instance for OOP interfaces which might help. Although I’m not sure how to map a callback handler in O(1) to the returned `CanardRxSubscription`, would `CanardRxSession` also include a user pointer then aswell?

> <https://github.com/UAVCAN/libcanard/issues/163>
>
> This is necessary to avoid double lookup in OOP interfaces built on top of libcanard. The idea is to add a...

Another solution would make an optimized data structure for mapping PortID efficiently to pointers/callbacks. But that feels more like re-inventing the wheel.

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [May 12, 2021, 2:55pm UTC](https://forum.opencyphal.org/t/libcanard-calling-canardrxaccept-handler-in-o-1-time/1257/2 "2021-05-12T14:55:50Z")

</div>

> [@PetervdPerk](#):
>
> On a system implementing many `CanardRxSubscription` instances you will end up with a big list to iterate trough when receiving a frame from `canardRxAccept` yielding a processing time of O(n).

This is correct, although keep in mind that if the subscription configuration is constant, then so is the processing time (`O(n), n = const`). This complexity does not depend on the network configuration, therefore the temporal properties of the local application are robustly predictable.

> [@PetervdPerk](#):
>
> Pavel made a proposal to change `canardRxAccept()` by adding a pointer to the associated `CanardRxSession` instance for OOP interfaces which might help. Although I’m not sure how to map a callback handler in O(1) to the returned `CanardRxSubscription`, would `CanardRxSession` also include a user pointer then aswell?

Yes. Actually, I already have this implemented in a private fork. Should I send a pull request against the upstream? Would you be available to write a basic unit test for this?

---

<div class="post-metadata">

**Author:** ![PetervdPerk](https://forum.opencyphal.org/letter_avatar_proxy/v4/letter/p/bbe5ce/32.png) [@PetervdPerk](https://forum.opencyphal.org/u/PetervdPerk)\
**Post date:** [May 12, 2021, 5:29pm UTC](https://forum.opencyphal.org/t/libcanard-calling-canardrxaccept-handler-in-o-1-time/1257/3 "2021-05-12T17:29:52Z")

</div>

Hi Pavel,

If you could make your fork public, I could test it next week and if it solves the problem I’ve got.  
I can write a unit test for it.