Bug 32087 - If one object is registered on multiple connections then signals are sent only to first connection
Summary: If one object is registered on multiple connections then signals are sent onl...
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: GLib (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Simon McVittie
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords:
Depends on: 36793
Blocks: 36811
  Show dependency treegraph
 
Reported: 2010-12-03 13:38 UTC by Rohan
Modified: 2011-06-01 02:47 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
[PATCH 1/4] fd.o #32087: emit signals on the appropriate connections (3.43 KB, patch)
2011-05-03 10:57 UTC, Simon McVittie
Details | Splinter Review
[PATCH 2/4] Add a regression test for registering an object on two connections (4.73 KB, patch)
2011-05-03 10:57 UTC, Simon McVittie
Details | Splinter Review
[PATCH 3/4] dbus_g_connection_unregister_g_object: only unregister from @connection (1.54 KB, patch)
2011-05-03 10:57 UTC, Simon McVittie
Details | Splinter Review
[PATCH 4/4] Add a regression test for removing an object from only one connection (1.34 KB, patch)
2011-05-03 10:58 UTC, Simon McVittie
Details | Splinter Review
test case for an object with many locations (7.23 KB, patch)
2011-05-30 05:30 UTC, Simon McVittie
Details | Splinter Review

Description Rohan 2010-12-03 13:38:09 UTC
If one Object is registered on multiple connections, then when a signal is emitted only the first registered connection gets the signal.
Comment 1 Simon McVittie 2011-05-03 10:15:58 UTC
This turns out to be related to Bug #36793.
Comment 2 Simon McVittie 2011-05-03 10:56:11 UTC
Ready for review, prerequisite for Bug #36811.
Comment 3 Simon McVittie 2011-05-03 10:57:01 UTC
Created attachment 46295 [details] [review]
[PATCH 1/4] fd.o #32087: emit signals on the appropriate connections

(This fixes the bug as filed.)
Comment 4 Simon McVittie 2011-05-03 10:57:32 UTC
Created attachment 46296 [details] [review]
[PATCH 2/4] Add a regression test for registering an object on two  connections
Comment 5 Simon McVittie 2011-05-03 10:57:55 UTC
Created attachment 46297 [details] [review]
[PATCH 3/4] dbus_g_connection_unregister_g_object: only unregister  from @connection

Previously, we unregistered the object from all connections, if it was
present on more than one.
Comment 6 Simon McVittie 2011-05-03 10:58:13 UTC
Created attachment 46298 [details] [review]
[PATCH 4/4] Add a regression test for removing an object from only  one connection
Comment 7 Cosimo Alfarano 2011-05-06 08:59:39 UTC
All the 4 patches looks OK.
Comment 8 Simon McVittie 2011-05-27 03:44:02 UTC
Fixed in git for 0.94, based on review from Cosimo and no objections from the reviewer group.
Comment 9 Rohan 2011-05-27 13:44:40 UTC
From the latest git all the connections receive the signal but,

If there are n registrations to the service, (i.e the same object registered on n separate connections) 
The first registered client receives n signals, the second registered client receives n-1 and so on and the last registered client receives one signal.
Comment 10 Simon McVittie 2011-05-30 01:34:01 UTC
(In reply to comment #9)
> From the latest git all the connections receive the signal but,
> 
> If there are n registrations to the service, (i.e the same object registered on
> n separate connections) 
> The first registered client receives n signals, the second registered client
> receives n-1 and so on and the last registered client receives one signal.

That doesn't sound right, but what exactly do you mean by "client" here? Please provide a simple test-case for this (with 3 clients, perhaps).
Comment 11 Simon McVittie 2011-05-30 05:30:52 UTC
Created attachment 47313 [details] [review]
test case for an object with many locations

Rohan: I'd expect this test case to reproduce the problem you reported, but it doesn't. How does your situation differ?
Comment 12 Rohan 2011-05-30 23:50:28 UTC
I am using a dbus server, (dbus_server_listen)
whenever  a client opens a connection, I register the same object (GObject)  to every client.(at the same object path.)
each client is a different process doing a connection open. 
If there are N client processes connected to the server , then 
The first process to which the object is registered will receive N signals. (i.e the signal handler gets called N times) 
when a client closes the connection, the object is unregistered.


(In reply to comment #11)
> Created an attachment (id=47313) [details]
> test case for an object with many locations
> 
> Rohan: I'd expect this test case to reproduce the problem you reported, but it
> doesn't. How does your situation differ?
Comment 13 Simon McVittie 2011-05-31 09:02:26 UTC
(In reply to comment #12)
> I am using a dbus server, (dbus_server_listen)
> whenever  a client opens a connection, I register the same object (GObject)  to
> every client.(at the same object path.)
> each client is a different process doing a connection open. 
> If there are N client processes connected to the server , then 
> The first process to which the object is registered will receive N signals.
> (i.e the signal handler gets called N times) 
> when a client closes the connection, the object is unregistered.

Can you show me your code?

In the clients, are you using DBusGProxy or something lower-level?
Comment 14 Simon McVittie 2011-05-31 10:14:29 UTC
(In reply to comment #9)
> From the latest git

Which git commit are you using? If it doesn't have at least commits c3c6f836 "dbus_g_connection_register_g_object: only hook onto signals on first use" and 818b900 "dbus_g_connection_unregister_g_object: only unregister from @connection" in its history, expect to get registration-related bugs.

(In reply to comment #12)
> If there are N client processes connected to the server , then 
> The first process to which the object is registered will receive N signals.
> (i.e the signal handler gets called N times) 
> when a client closes the connection, the object is unregistered.

It sounds as though you may be hitting part of Bug #36811, fixed by commit c3c6f836.
Comment 15 Rohan 2011-05-31 10:37:59 UTC
Hi,
It could be.
I dont see the problem.
The changes are working fine from the latest git.(06/31/2011)
Comment 16 Simon McVittie 2011-06-01 02:47:40 UTC
(In reply to comment #15)
> The changes are working fine from the latest git.(06/31/2011)

Closing this bug again, then.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.