-
Notifications
You must be signed in to change notification settings - Fork 2.2k
[Tizen] Properly implement BLEManagerImpl::_NumConnections #39965
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
The pull request implements _NumConnections
to return the actual number of BLE connections. The review focuses on a potential race condition when accessing the shared connection map and suggests adding thread synchronization using the platform's locking mechanism to ensure data integrity.
PR #39965: Size comparison from c0a78ce to 0258186 Full report (70 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, cyw30739, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink)
|
0258186
to
208374f
Compare
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request implements _NumConnections
by switching from GHashTable
to std::unordered_map
for managing BLE connections, which improves type safety and simplifies the code. The PR also fixes a memory leak in _GetDeviceName
and simplifies parameter validation in several functions. There is a critical operator precedence bug that needs to be addressed, and a high-severity logic issue in CloseConnection
that could lead to race conditions and confusing logs.
int ret = bt_gatt_disconnect(conId->peerAddr.c_str()); | ||
VerifyOrExit(ret == BT_ERROR_NONE, ChipLogError(DeviceLayer, "bt_gatt_disconnect() failed: %s", get_error_message(ret))); | ||
|
||
RemoveConnectionData(conId->peerAddr); | ||
RemoveConnection(conId->peerAddr.c_str()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling RemoveConnection
here can lead to a race condition and confusing logs. The bt_gatt_disconnect
function is asynchronous and will trigger a ConnectionStateChangedCb
callback upon completion, which in turn calls HandleConnectionEvent
and then RemoveConnection
.
This means the connection is removed twice: once synchronously here, and again asynchronously in the event handler. While the current implementation of RemoveConnection
is safe against a double-free, it will log an error when the connection is not found on the second call. To avoid this, I recommend removing the synchronous call to RemoveConnection
and relying solely on the event handler for cleanup. This ensures a single, consistent point of state management for connection removal.
PR #39965: Size comparison from ad2e3f5 to b867e84 Increases above 0.2%:
Full report (59 builds for bl602, bl702, bl702l, cc13x4_26x4, cc32xx, efr32, esp32, linux, nrfconnect, nxp, psoc6, qpg, stm32, telink, tizen)
|
Summary
The
chip::DeviceLayer::ConnectivityMgr().NumBLEConnections()
always returns 0 because underlying implementation was incorrect.Changes
Testing
Locally verified that the application can check whether there is an ongoing BLE connection.