D-BUS implementing DCOP - some minor problems?
Waldo Bastian
bastian@kde.org
Wed Jan 26 06:20:37 PST 2005
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?
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.
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.
Cheers,
Waldo
--
bastian@kde.org | Free Novell Linux Desktop 9 Evaluation Download
bastian@suse.com | http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050126/769ab9d1/attachment.pgp
More information about the dbus
mailing list