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.

[helpfulchicken]

I think a subtle problem is that the documentation of bt_gatt_notify (link: https://docs.zephyrproject.org/latest/connectivity/bluetooth/api/gatt.html#c.bt_gatt_notify) doesn't tell us that it is blocking if called enough times without the notify attempts resolving. This can cause unbounded delays in certain scenarios and the user has no idea that this function can be blocking.

[ErnestVanHoecke]

I was looking for a place to raise the same issue. This just cost me some time and it's not very clear that this can block in such a manner. The blocks can become extremely long as well as you've said.

In our use case we really want to maximize throughput while minimizing latency. I will probably add a separate thread (workqueue) to handle the sends.

Also a very important note:

Adding the send work to the system work queue will make the send (partially) non-blocking. This means that if no TX buffer is available, the send will fail instead of waiting until it can get a buffer and sending at that time. So if you use the system workqueue, make sure you are resubmitting failed sends to the queue if you want them to get through.

This is not the case when using a different workqueue. In that case, the send (inside the workqueue) will block until the buffer is acquired. But since the buffer is freed inside the workqueue, the ATT system makes an exception for the system workqueue because it would never acquire the buffer. 

This is something I noticed because I first did not realise this system was blocking and started debugging until I found that the block usually occurs in tx_meta_data_alloc inside att.c, which has a comment explaining the above.