gatt: properly call connection callback when connection is already up
the callback might be called before this func returnes (talk
to your scheduler about that). This leaves you with a conundrum:
How will you know the callback is for you when you do not yet
know thw connection id. Caller solves this themselves. eg: take
a mutex in callback, and also take it before calling this, do
not release it till this func returns.
BUG=b:74813838,crbug:905047
TEST=test app unbroken
Change-Id: Ie4918e525057e228695b2f2bfa1d9fb96c180899
diff --git a/gatt.c b/gatt.c
index 1c51f1a..bc4c7f4 100644
--- a/gatt.c
+++ b/gatt.c
@@ -1566,7 +1566,12 @@
* PARAMS: to - whom to connect to
* resultCbk - will be called with results
* RETURN: connection id or 0 on failure
- * NOTES:
+ * NOTES: the callback might be called before this func returnes (talk
+ * to your scheduler about that). This leaves you with a conundrum:
+ * How will you know the callback is for you when you do not yet
+* know thw connection id. Caller solves this themselves. eg: take
+ * a mutex in callback, and also take it before calling this, do
+ * not release it till this func returns.
*/
gatt_client_conn_t gattClientConnect(const struct bt_addr *to, gattCliConnectResultCbk resultCbk)
{
@@ -1596,6 +1601,10 @@
clicon->connId = uniqGetNext();
clicon->connCbk = resultCbk;
+ // call callback right away?
+ if (inst->state == GATT_CONN_STATE_RUNNING)
+ gattEnqueueCliConnStatusCall(clicon, GATT_CLI_STATUS_OK);
+
// success!
ret = clicon->connId;
pthread_mutex_unlock(&mGattLock);
