DCOPserver bug with broadcasts
Waldo Bastian
bastian at kde.org
Mon Jul 14 12:49:45 BST 2003
-----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-----
More information about the kde-core-devel
mailing list