D-BUS implementing DCOP - some minor problems?
Maks Orlovich
mo85 at cornell.edu
Wed Jan 26 15:58:15 GMT 2005
On Wednesday 26 January 2005 09:20 am, Waldo Bastian wrote:
> On Wednesday 26 January 2005 07:22, David A. Wheeler wrote:
> > When I said:
> > >>* DCOP's "send" can actually do a broadcast to a set of applications,
> > >> e.g., sending to 'konsole-*' will send to all apps called console.
> > >> D-BUS should implement a 'limited broadcast'; I wouldn't be
> > >> surprised if it does, I just don't see anything about it.
> >
> > Havoc replied:
> > > Doing this for normal method calls breaks dbus entirely, because
> > > replies are matched by the serial in the outgoing message. We could
> > > perhaps allow it iff NO_REPLY_EXPECTED is set.
> >
> > Yes, that seems to be the DCOP use... you can send to a wildcard, but
> > only if there will be no reply. It seems to me that D-BUS should
> > permit method calls without returns to do a broadcast, especially
> > since broadcasts are already built-in for signals.
> > Lacking a broadcast ability also seems very inefficient for busses;
> > currently to do a method 'broadcast' (NO_REPLY_EXPECTED), a D-BUS
> > user has to send #receivers * ( 1 [sender->bus] + 1 [bus->receiver) ]
> > messages. If it had a built-in broadcast mechanism, then a broadcast
> > only requires 1 [sender->bus] + #receivers [bus->receiver] messages.
> > And it'd be easier too.
> >
> > In my mind, having some sort of broadcast capability makes sense.
> >
> > Indeed, this makes me wonder again if there's
> > a need for in method calls to allow three reply states:
> > 'normal' (please reply), 'NO_REPLY_EXPECTED', and a 'DO_NOT_REPLY'
> > tri-state. It might be easier for a separate monitor to detect potential
> > deadlocks if the messages carried more information, including information
> > on whether or not they're expecting a reply.
>
> I don't think it would matter if someone were to reply to a broadcast, such
> reply would/should just be discarded.
>
> I would like to note that broadcasts were added to DCOP before we had
> DCOP-signals. I think signals are a much better solution than broadcasts
> because they are much more efficient. The downsides of broadcasts are
> basically:
>
> 1) It fits poor with general object oriented design to use broadcasts to
> targets like "mozilla-*", what if later on someone starts to use
> "firefox-xxx" as name?
We actually have a bug sort of based on this. KonqHistoryManager does
broadcasts to konqueror-*, but the universal sidebar does a history view
inside a kicker process => it does not receive update notifications.
Hmm, it should probably add a second call to 'kicker' then, shouldn't be /too/
horrid performance-wise, though quite ugly. ..
(If you only care about D-BUS, skip this bit, it's me rambling about stuff KDE
may or may not need)
Though, I must add that we also have a similar thing done for /bookmarks/, but
it uses DCOP signals -- good, but synchronization is happening exclusively
via the file --- bad. It may be nice to have something common for those two
that helps keep things up-to-date, and handle the highly tricky case of the
owner of the file exiting (though we probably still want to sync to the disk
to help the starting apps --- though have to be careful not to have a race
between reading a file and new updates -- timestamps, here we come!); though
making this nicely performing and completely race free would be quite
difficult; anyway, I digress.
> 2) Broadcasts to "*" are very bad for system performance, you end up waking
> up all client-processes on the bus. Most of the time you only try to reach
> a subset of clients.
Do you have an example in mind?
> 3) You run the risk of calling non-existent methods/objects. This shouldn't
> be a problem in itself but it may cause excessive warning messages. DBUS
> itself should take care not to send error messages back on the bus. (Does
> it do so when NO_REPLY_EXPECTED is set?)
>
> So given the above, and given the fact that clients can create broadcasts
> manually by querying the list of available clients for the rare cases that
> they really need it, I don't think that having special broadcast support
> in DBUS is required.
And I suppose you can emulate them with a signal, i.e. have a
"DCOPkonqueror-*",
group which all konqy's join, and then emit signals w/a message marshalled to
emulate the broadcast. Yeah, sort of ugly, and I am not sure whether the
demarshalling setup permits that sort of encapsulation.
-Maks
More information about the kde-core-devel
mailing list