Bug 32087

This turns out to be related to Bug #36793.

Ready for review, prerequisite for Bug #36811.

Created attachment 46295 [details] [review]
[PATCH 1/4] fd.o #32087: emit signals on the appropriate connections

(This fixes the bug as filed.)

Created attachment 46296 [details] [review]
[PATCH 2/4] Add a regression test for registering an object on two  connections

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.

Created attachment 46298 [details] [review]
[PATCH 4/4] Add a regression test for removing an object from only  one connection

All the 4 patches looks OK.

Fixed in git for 0.94, based on review from Cosimo and no objections from the reviewer group.

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.

(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).

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?

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?

(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?

(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.

Hi,
It could be.
I dont see the problem.
The changes are working fine from the latest git.(06/31/2011)

(In reply to comment #15)
> The changes are working fine from the latest git.(06/31/2011)

Closing this bug again, then.