DCOPserver bug with broadcasts

[Waldo Bastian]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 12 July 2003 11:52, David Faure wrote:
> Hi Waldo,
>
> Alex Kellett and I are looking at a problem with broadcasts in
> kbookmarkmanager. It appears to be possible to have multiple dcopclients in
> the same process, named like anonymous-<pid>-<number> (for some reason kget
> registers such a client). The problem is that when dcopserver propagates a
> broadcast (dcopserver.cpp:724) it will find all those dcopclients from the
> _same_ process, and call each one. In the process, we use a static map of
> dcopobjects, so the same object will be called multiple times (the
> dcopclient is just a "hook" into that process, the dcopobjects are not
> associated with the dcopclient).
>
> Do you have any suggestion on how we could fix it?

Don't use broadcasts but use DCOP signals instead. Most likely you are not 
interested in waking up every dcop-enabled process anyway, in which case a 
broadcast would be a first-rate performance killer.

> Somewhat I'd like 
> dcopserver to send a broadcast only once to every process, but it doesn't
> appear to know the pid of the process it's talking to (only ice
> connections)... is there a way to detect that it's talking multiple times
> to the same process?

The fundamental problem is that DCOPObject is not bound to a specific 
DCOPClient but instead bound to every DCOPClient. The broadcast behavior is 
in line with that. A solution would be to bind DCOPObjects implicitly to 
DCOPClient::mainClient() only and to have an option to bind/unbind them to 
one or or more other DCOPClients explicitly.

No idea if there are applications that rely on the current behavior. I know 
that kded also registers as kcookiejar for backwards compatibility and there 
you also see the problem that "dcop kcookiejar" shows alls kded objects while 
it should actually only show the kcookiejar object.

I suggest to add 
*) a DCOPObject constructor that accepts an initial DCOPClient * to bind to, 
defaulting to DCOPClient::mainClient() if none is provided.
*) DCOPObject::bindClient(DCOPClient *);
*) DCOPObject::unbindClient(DCOPClient *);
*) QPtrList<DCOPClient> DCOPObject::clients();

And to change the semantics so that dcop can only access objects in clients 
when those objects have been bound to the client. An object can be bound to 
multiple clients.

Note that DCOP signal support in DCOPObject currently uses 
"DCOPClient::mainClient()" to send out signals. I would change that then to 
use the first client the DCOPObject is (still) bound to instead.

The semantics might become a bit clearer if we force the DCOPClient <--> 
DCOPObject to be 1:1. That would break the kcookiejar mentioned above, but it 
would be easy to provide a	proxy DCOPObject that simply redirects from one 
dcop-object to another. DCOPObject would then need to be extended with:

*) a DCOPObject constructor that accepts an initial DCOPClient * to bind to, 
defaulting to DCOPClient::mainClient() if none is provided.
*) DCOPObject::bindClient(DCOPClient *); // To change the binding after 
construction
*) DCOPClient DCOPObject::dcopClient(); // Client it is bound to.

Where DCOPObject now uses DCOPClient::mainClient() it would then use 
DCOPObject::dcopClient()

I haven't been involved with DCOPObject much, so I would like to hear other 
people's opinion first (Simon? Ian?) I'm willing to implement it if there's 
concensus that this is desirable.

Cheers,
Waldo
- -- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/EpjaN4pvrENfboIRAuvpAJ9GE+KQI0a+Cm509eQEJ9i3G6ahFwCcCgKt
Y+TmqjO1336yDDaZ2EBBFd4=
=VogH
-----END PGP SIGNATURE-----