Open Source Telephony
 help / color / mirror / Atom feed
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

  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