From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH v3 4/7] ubloxmodem: add the netmon driver
Date: Thu, 01 Dec 2016 11:18:00 -0600 [thread overview]
Message-ID: <58405B48.5050003@gmail.com> (raw)
In-Reply-To: <CAH562ETeQh-wQ5EoDN6UVz0ZFOw6ci=ijizudSq+UgQgVieohA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]
Hi Djalal,
>
> OK thank you for the explanation. I did go with ref counting since
> they are easy to use and I will follow up later with +UCGED which has
> different behaviour depending on firmware version...
Sounds good.
>
> I take a ref just before doing the g_at_chat_send() , however I call
> unref in case g_at_chat_send() returns 0 and fails since in that case
> the GDestroyNotify is still not registered and the command was not
> queued...
That is fine. In general it might be simpler to have req_cb_data_ref
initialize the ref count to 1. Saves you a call to ref()
>
> Hmm so now maybe the leak may happen in this small window between:
> cbd = req_cb_data_ref(cbd);
> and
> g_at_chat_send() and before registering the GDestroyNotify
> parameter... in case hardware removal happens or anything... I'm not
> sure and I also don't know how to fix it.
This is not possible. The hardware removal notification still comes
over a socket, so regular event loop rules apply. The function
invocation won't be interrupted mid-stream.
What we're worried about is us allocating memory, queuing the command
into GAtChat, but at some point later, the GAtChat object is destroyed
before the command callback was executed.
Regards,
-Denis
next prev parent reply other threads:[~2016-12-01 17:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 12:31 [PATCH v3 0/7] ubloxmodem add netmon interface Djalal Harouni
2016-11-30 12:31 ` [PATCH v3 1/7] netmon: add OFONO_NETMON_INFO_{RSCP|ECN0|RSRQ|RSRP} Djalal Harouni
2016-11-30 15:27 ` Denis Kenzior
2016-11-30 12:31 ` [PATCH v3 2/7] netmon: handle OFONO_NETMON_INFO_{RSCP|ECN0|RSRQ|RSRP} in D-Bus Djalal Harouni
2016-11-30 15:31 ` Denis Kenzior
2016-11-30 12:31 ` [PATCH v3 3/7] doc: documentation for OFONO_NETMON_INFO_{RSCP|ECN0|RSRQ|RSRP} Djalal Harouni
2016-11-30 15:28 ` Denis Kenzior
2016-11-30 12:31 ` [PATCH v3 4/7] ubloxmodem: add the netmon driver Djalal Harouni
2016-11-30 15:55 ` Denis Kenzior
2016-12-01 13:39 ` [PATCH v4 " Djalal Harouni
2016-12-01 13:51 ` [PATCH v3 " Djalal Harouni
2016-12-01 17:18 ` Denis Kenzior [this message]
2016-12-05 14:28 ` Djalal Harouni
2016-12-01 13:59 ` [PATCH v5 " Djalal Harouni
2016-12-01 17:29 ` Denis Kenzior
2016-12-05 14:29 ` Djalal Harouni
2016-11-30 12:31 ` [PATCH v3 5/7] ubloxmodem: register and initialize " Djalal Harouni
2016-11-30 12:31 ` [PATCH v3 6/7] build: build the ublox " Djalal Harouni
2016-11-30 12:31 ` [PATCH v3 7/7] test: support OFONO_NETMON_INFO_{RXLEV|RSCP|ECN0|RSRQ|RSRP} Djalal Harouni
2016-11-30 15:56 ` Denis Kenzior
2016-12-01 13:52 ` Djalal Harouni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58405B48.5050003@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox