[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: D-BUS implementing DCOP - some minor problems?
From:       Maks Orlovich <mo85 () cornell ! edu>
Date:       2005-01-26 15:58:15
Message-ID: 200501261058.15670.mo85 () cornell ! edu
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]