Hi Alex,
On 7/30/21 8:21 AM, ajlen...@dynamicdevices.co.uk wrote:
I'm not sure what you mean? What exactly do you think needs freeing?
Strange. I am lookinga at the drivers and sometimes unref functions are
provided into other functions and sometimes not
So you're talking about callbacks in the driver itself, not actually crossing
the core<->driver boundary.
There aren't really any docs, but g_at_chat acts just like any other GLib based
library (or many main-loop driven C libraries for that matter), so pretty much
the same rules apply. I can give you some hints...
if (g_at_chat_send(nmd->chat, "AT+QENG=\"servingcell\"", qeng_prefix,
qeng_cb, cbd, req_cb_data_unref) == 0) {
Under the hood, g_at_chat_send puts a request on the queue. And the request
might not be processed until some time later. It can also be interrupted and
cleaned up without the callback being called (if the hardware gets pulled for
example). So if you're passing any allocated userdata, you need to provide a
'destroy' method to de-allocate it, otherwise it will leak.
In your example, cbd is userdata and req_cb_data_unref is the destroy method,
respectively.
Oh, and req_cb_data is a common pattern. It is used where you need to run
several commands in sequence (think of it as a transaction) and the allocated
userdata needs to be cleaned up even if the transaction is interrupted.
Then these CALLBACK_WITH_FAILURE and CALLBACK_WITH_SUCCESS calls sometimes seem
to have free functions after them and sometimes not.
There is definitely a reason why they do. Hopefully the explanation above
helps.
Regards,
-Denis
_______________________________________________
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org
