You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(Please close if my analysis is incorrect - my code type-checks but I have not run it yet.)
It seems to me that calling Server::new_with_config a second time will panic, because the hidden AttributeTable uses a bunch of hidden StaticCells for its storage. Wouldn't calling it a second time end up with a panic, because you would be calling StaticCell::init twice?
In my use case, I do need the ability to call Server::new_with_config twice, because I need to support dynamic BLE stack tear-down / bring-up.
I can (and will) fix that with workarounds, like having an async mutex, that in turn contains Option<Server> and then I'll initialize the mutex on first use.
With that said, it is still a bit weird. As in the proc-macro bails with an error if you don't have the static_cell dependency in your crate (as was my case). Otherwise, I might not have even noticed that.
Also:
Isn't it better to have the necessary &mut [u8; <SUM_OF_ALL_GATT_ATTR_STORAGES>] storage be instead an argument to Server::new_with_config (ideally not &'static mut but &'some_lifetime mut)? This way you can trivially initialize the server multiple times, there is no dependency on static-cell in the proc-macro, and it is a bit more explicit to the user what is going on under the hood?
Why is this storage necessary in the first place? As in - the storage of the "level" attr right here should be the member variable itself? level: u8? Why a second storage in the form of a buffer? (Update: seems the level: u8 field is actually never materialized. It is just a hint how much storage to actually allocate in the attribute table, and then is also used for the T in Characteristic<T>.)
The text was updated successfully, but these errors were encountered:
I think the simpler we can make the macros deal with the common cases, the better. If you need more advanced functionality, there is always the option of using the underlying API (though the only example of that right now is https://github.com/embassy-rs/trouble/blob/main/host/tests/gatt.rs#L46
(Please close if my analysis is incorrect - my code type-checks but I have not run it yet.)
It seems to me that calling
Server::new_with_config
a second time will panic, because the hiddenAttributeTable
uses a bunch of hiddenStaticCell
s for its storage. Wouldn't calling it a second time end up with a panic, because you would be callingStaticCell::init
twice?In my use case, I do need the ability to call
Server::new_with_config
twice, because I need to support dynamic BLE stack tear-down / bring-up.I can (and will) fix that with workarounds, like having an async mutex, that in turn contains
Option<Server>
and then I'll initialize the mutex on first use.With that said, it is still a bit weird. As in the proc-macro bails with an error if you don't have the
static_cell
dependency in your crate (as was my case). Otherwise, I might not have even noticed that.Also:
&mut [u8; <SUM_OF_ALL_GATT_ATTR_STORAGES>]
storage be instead an argument toServer::new_with_config
(ideally not&'static mut
but&'some_lifetime mut
)? This way you can trivially initialize the server multiple times, there is no dependency on static-cell in the proc-macro, and it is a bit more explicit to the user what is going on under the hood?Why is this storage necessary in the first place? As in - the storage of the "level" attr right here should be the member variable itself?(Update: seems thelevel: u8
? Why a second storage in the form of a buffer?level: u8
field is actually never materialized. It is just a hint how much storage to actually allocate in the attribute table, and then is also used for theT
inCharacteristic<T>
.)The text was updated successfully, but these errors were encountered: