Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.01.org/mailman/listinfo/connman
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: DBus properties race condition (Patrik Flykt)
2. Re: DBus properties race condition (Slava Monich)
3. Re: DBus properties race condition (Richard R?jfors)
4. Re: DBus properties race condition (Patrik Flykt)
5. Re: [PATCH 1/2] dhcpv6: Return -EISCONN when the expiry time
is inifinite (Patrik Flykt)
6. Re: DBus properties race condition (David Lechner)
----------------------------------------------------------------------
Message: 1
Date: Fri, 15 Jul 2016 10:34:32 +0300
From: Patrik Flykt <[email protected]>
To: David Lechner <[email protected]>, [email protected]
Subject: Re: DBus properties race condition
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Hi,
On Thu, 2016-07-14 at 11:10 -0500, David Lechner wrote:
> Here is what is going on:
>
> When implementing a ConnMan client, the docs say to use, for example,
> Manager.GetTechnologies() instead of the deprecated
> Technology.GetProperties() method. However, if I follow this advice,
> there is a race condition where property changes can be missed. I
> have observed this first hand and I also found a bug against connman-
> qt that is explaining the same situation[1].
>
> Pseudo code goes like this:
> manager_proxy = get_proxy("net.connman", "/", "net.connman.Manager")
> technologies = manager_proxy.GetTechnologies()
> foreach (technology in technologies) {
> ??? technology_proxy = get_proxy("net.connman", technology.Path,
> "net.connman.Technology")
> ??? technology_proxy.connect_signals() <-- Properties can change in the time
> between the call to GetTechnologies() and when we connect signals!
> ??? technology_proxy.set_properties(technology.properties)
Done this way, yes, some technologies or their properties can be
missed. The simple "trick" to fix this is to connect the signals first,
then to request all technologies. Done that way, every update after
fetching the technologies will be noticed.
HTH,
Patrik
------------------------------
Message: 2
Date: Fri, 15 Jul 2016 12:50:01 +0300
From: Slava Monich <[email protected]>
To: [email protected]
Subject: Re: DBus properties race condition
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 15/07/16 10:34, Patrik Flykt wrote:
>
> Hi,
>
> On Thu, 2016-07-14 at 11:10 -0500, David Lechner wrote:
>> Here is what is going on:
>>
>> When implementing a ConnMan client, the docs say to use, for example,
>> Manager.GetTechnologies() instead of the deprecated
>> Technology.GetProperties() method. However, if I follow this advice,
>> there is a race condition where property changes can be missed. I
>> have observed this first hand and I also found a bug against connman-
>> qt that is explaining the same situation[1].
>>
>> Pseudo code goes like this:
>> manager_proxy = get_proxy("net.connman", "/", "net.connman.Manager")
>> technologies = manager_proxy.GetTechnologies()
>> foreach (technology in technologies) {
>> technology_proxy = get_proxy("net.connman", technology.Path,
>> "net.connman.Technology")
>> technology_proxy.connect_signals() <-- Properties can change in the
>> time between the call to GetTechnologies() and when we connect signals!
>> technology_proxy.set_properties(technology.properties)
>
> Done this way, yes, some technologies or their properties can be
> missed. The simple "trick" to fix this is to connect the signals first,
> then to request all technologies. Done that way, every update after
> fetching the technologies will be noticed.
>
That's not as simple as it may sound. Since you don't know the
technology paths in advance, you would have to register the match for
any path, cache the changes while GetTechnologies is pending and then
distribute the signals to the right objects, essentially duplicating the
functionality provided by popular D-Bus APIs, such as Qt or gio.
-Slava
> HTH,
>
> Patrik
>
>
------------------------------
Message: 3
Date: Fri, 15 Jul 2016 11:57:08 +0200
From: Richard R?jfors <[email protected]>
To: [email protected]
Subject: Re: DBus properties race condition
Message-ID:
<CAHB-Pjn8Na0MoYbBKqFvzqPoqtbgpJzed+y2=uwco5y-vjb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Oops, sorry, did a private reply. Copying the list.
On Fri, Jul 15, 2016 at 10:17 AM, Richard R?jfors <[email protected]
> wrote:
> On Fri, Jul 15, 2016 at 9:34 AM, Patrik Flykt <
> [email protected]> wrote:
>
>> >
>> > Pseudo code goes like this:
>> > manager_proxy = get_proxy("net.connman", "/", "net.connman.Manager")
>> > technologies = manager_proxy.GetTechnologies()
>> > foreach (technology in technologies) {
>> > technology_proxy = get_proxy("net.connman", technology.Path,
>> "net.connman.Technology")
>> > technology_proxy.connect_signals() <-- Properties can change in the
>> time between the call to GetTechnologies() and when we connect signals!
>> > technology_proxy.set_properties(technology.properties)
>>
>> Done this way, yes, some technologies or their properties can be
>> missed. The simple "trick" to fix this is to connect the signals first,
>> then to request all technologies. Done that way, every update after
>> fetching the technologies will be noticed.
>>
>
> But how would you know which object paths to connect the signals to?
>
> Call get technologies twice? And connect after the first call?
>
> --Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.01.org/pipermail/connman/attachments/20160715/f7a971a1/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 15 Jul 2016 13:19:44 +0300
From: Patrik Flykt <[email protected]>
To: Slava Monich <[email protected]>, [email protected]
Subject: Re: DBus properties race condition
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Fri, 2016-07-15 at 12:50 +0300, Slava Monich wrote:
> On 15/07/16 10:34, Patrik Flykt wrote:
> >
> > Hi,
> >
> > On Thu, 2016-07-14 at 11:10 -0500, David Lechner wrote:
> > > Here is what is going on:
> > >
> > > When implementing a ConnMan client, the docs say to use, for
> > > example,
> > > Manager.GetTechnologies() instead of the deprecated
> > > Technology.GetProperties() method. However, if I follow this
> > > advice,
> > > there is a race condition where property changes can be missed. I
> > > have observed this first hand and I also found a bug against
> > > connman-
> > > qt that is explaining the same situation[1].
> > >
> > > Pseudo code goes like this:
> > > manager_proxy = get_proxy("net.connman", "/",
> > > "net.connman.Manager")
> > > technologies = manager_proxy.GetTechnologies()
> > > foreach (technology in technologies) {
> > > ?????technology_proxy = get_proxy("net.connman", technology.Path,
> > > "net.connman.Technology")
> > > ?????technology_proxy.connect_signals() <-- Properties can change
> > > in the time between the call to GetTechnologies() and when we
> > > connect signals!
> > > ?????technology_proxy.set_properties(technology.properties)
> >
> > Done this way, yes, some technologies or their properties can be
> > missed. The simple "trick" to fix this is to connect the signals
> > first,
> > then to request all technologies. Done that way, every update after
> > fetching the technologies will be noticed.
> >
>
>
> That's not as simple as it may sound. Since you don't know the?
> technology paths in advance, you would have to register the match for?
> any path, cache the changes while GetTechnologies is pending and then?
> distribute the signals to the right objects, essentially duplicating the?
> functionality provided by popular D-Bus APIs, such as Qt or gio.
Oh yes, I'm indeed corrected. GetProperties() to the rescue it is.
Fixing the D-Bus API is a task for the next major version of ConnMan,
so we'll stay with this API for a while still.
Cheers,
Patrik
------------------------------
Message: 5
Date: Fri, 15 Jul 2016 15:40:50 +0300
From: Patrik Flykt <[email protected]>
To: Feng Wang <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH 1/2] dhcpv6: Return -EISCONN when the expiry time
is inifinite
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
On Thu, 2016-07-14 at 11:07 -0700, Feng Wang wrote:
> Hi Patrik,
>
> I tried the 2 patches.? They are working.
>
> Thanks,
>
> Feng
Thanks very much for testing! And pointing out the issue!
Both patches have been applied.
Patrik
------------------------------
Message: 6
Date: Fri, 15 Jul 2016 11:49:56 -0500
From: David Lechner <[email protected]>
To: [email protected]
Subject: Re: DBus properties race condition
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 07/15/2016 05:19 AM, Patrik Flykt wrote:
> On Fri, 2016-07-15 at 12:50 +0300, Slava Monich wrote:
>> On 15/07/16 10:34, Patrik Flykt wrote:
>>> Hi,
>>>
>>> On Thu, 2016-07-14 at 11:10 -0500, David Lechner wrote:
>>>> Here is what is going on:
>>>>
>>>> When implementing a ConnMan client, the docs say to use, for
>>>> example,
>>>> Manager.GetTechnologies() instead of the deprecated
>>>> Technology.GetProperties() method. However, if I follow this
>>>> advice,
>>>> there is a race condition where property changes can be missed. I
>>>> have observed this first hand and I also found a bug against
>>>> connman-
>>>> qt that is explaining the same situation[1].
>>>>
>>>> Pseudo code goes like this:
>>>> manager_proxy = get_proxy("net.connman", "/",
>>>> "net.connman.Manager")
>>>> technologies = manager_proxy.GetTechnologies()
>>>> foreach (technology in technologies) {
>>>> technology_proxy = get_proxy("net.connman", technology.Path,
>>>> "net.connman.Technology")
>>>> technology_proxy.connect_signals() <-- Properties can change
>>>> in the time between the call to GetTechnologies() and when we
>>>> connect signals!
>>>> technology_proxy.set_properties(technology.properties)
>>> Done this way, yes, some technologies or their properties can be
>>> missed. The simple "trick" to fix this is to connect the signals
>>> first,
>>> then to request all technologies. Done that way, every update after
>>> fetching the technologies will be noticed.
>>>
>>
>> That's not as simple as it may sound. Since you don't know the
>> technology paths in advance, you would have to register the match for
>> any path, cache the changes while GetTechnologies is pending and then
>> distribute the signals to the right objects, essentially duplicating the
>> functionality provided by popular D-Bus APIs, such as Qt or gio.
> Oh yes, I'm indeed corrected. GetProperties() to the rescue it is.
> Fixing the D-Bus API is a task for the next major version of ConnMan,
> so we'll stay with this API for a while still.
>
>
> Cheers,
>
> Patrik
> _______________________________________________
> connman mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/connman
Thanks for the feedback. I'll keep using the deprecated GetProperties()
then. It would be nice to use org.freedesktop.DBus.Properties in ConnMan
2.0.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list
[email protected]
https://lists.01.org/mailman/listinfo/connman
------------------------------
End of connman Digest, Vol 9, Issue 8
*************************************
