bt_gatt_write_without_response_cb / bt_gatt_notify: how to prevent blocking

[rgrr2]

Hello,

calls to the above functions block the caller if internal queues become full.  Because my application is running in a big loop, I need those functions without blocking (a specific return code would suffice).

Is there any way to prevent those functions from blocking?  Or is there another non-blocking API doing similar things?

Thanks & regards

Hardy

PS: my current workaround is a small extra thread for packet transmission which is allowed to block (extra buffer, extra stack, extra copy operation).  But this seems to be like using a sledge-hammer to crack a nut

[Susheel Nuguru]

Any callback function that is designed to run on system queue has a default behavior to block until the queue have free space. There are few exceptions to this but those exceptions are not for these API. No there is no other alternative provided for this API unfortunately. Using system queue was a design choice here.

[rgrr2]

Thanks for reply.  Any chance to check if the call would go into blocking?

[Susheel Nuguru]

Unfortunately no, not from the application side. Changes would have to be made to the zephyr\subsys\bluetooth\host\att.c to expose the pointers where the application might get ability to query if the k_fifo that the attribute is about to use is full or not.

[helpfulchicken]

personally I have dealt with the issue by using bt_gatt_notfiy_cb to have a custom function called when the notify completes. That clears a flag to let me know that particular gatt request has completed. The flag is also manually cleared if we have a disconnection event with the peer being notified. Then I basically just don't use bt_gatt_notify_cb if my flag says a gatt request hasn't been resolved - no more issue with blocking.

[rgrr2]

This does unfortunately not help if you want to send more than one packet a time.  I'm trying to optimize for speed, because in our application data transfer is done via bt_gatt_notify*(), so I want to transfer as much packets as possible (*) per connection event.

(*) half true: actually I have to take current consumption into account