RFC: DBUS & KDE 4
Maks Orlovich
mo85 at cornell.edu
Thu Sep 30 18:10:23 BST 2004
On Thursday 30 September 2004 12:36 pm, Aaron Seigo wrote:
> On September 30, 2004 10:04, Maks Orlovich wrote:
> > > [*] Just consider Aaron and his systray-over-DBUS.
>
> hehe =P
>
> > See, that's partly why I am really uncomfortable about this stuff. It's
> > 90% buzz, 10% technology. And buzz has rather circural nature: people get
> > convinced that everyone will use X, so everyone ends up using X.
>
> to say it again: i'm using it because it has things DCOP doesn't. it would
> simply not be feasable to do what i'm doing with DCOP. it's either XAtoms
Which is?
> > D-BUS hardly excites me because I don't see anything particularly
> > innovative in it (while DCOP's very existance was quite a radical idea,
> > and the whole key/call causality tracing things is interesting). D-BUS
> > seems
>
> not everything has to be innovative. in fact, innovative ideas become
> mundane but often stick around for a long time anyways because they are
well, but why get excited about something that doesn't do anything substantial
that -we- haven't done already? Well, OK, it's an OSS project with a huge
marketing department. But that's not for pure techies like me. (Although
people who can write well, such that Aaron Seigo dude w/that funky beard
might care)
> unless there is something better, there's nothing wrong with such a
> situation. though you seem to imply that there could be a greater
> innovation here. what would that be, in your mind?
Well, i.e., I've done a dcop-like system which guarantees exact memory
management and error-handling semantics in presence of aggressively
asynchronous call interface. And that was just a term project, yet it had
some difficult problems to solve which were more than just "whee, this can use
libsasl!". (This was motivated, BTW, by bugno:68905, and a discussion w/Ian
on how to solve this). If D-Bus could do this sort of thing, and w/o the
limitations my solution had (and the braindamages in the implementation),
I would be impressed and probably singing praises. Right now it's just vanilla
RPC w/a library that does some useful transport stuff, and w/a woefully
under-defined spec.
>
> > so ended up making some things worse w/some things better, while
> > reproducing a lot of the really mundane stuff.
>
> the question has be posed, but not answered: can the "stuff that is worse"
> be fixed and how much effort would that take? i know earlier you spoke
> about deadlock issues, can you point to where these problems exist
> exactly[1]?
Well, again, it would help if the D-Bus spec specified a lot of the more
complex stuff involved, wrt to blocking/non-blocking call semantics
but consider this situation:
1. You're a program you make an outgoing call.
2. You get an incoming call
so what do you do? Well, you could handle it. But that can cause unwanted
reentrancy. Or you could defer the call until the outgoing call finishes. But
that can cause deadlock.
What DCOP does is the following: it handles the message if it's marked
high-priority[1], or if not handling it would cause a deadlock. It does so by
tracing the causality of the blocking calls.
Now, why does this stuff matter? I agree that you could argue that this sort
of thing is not always needed, since it can just replace a deadlock with a
reentrancy bug (although I think the former may be more severe in some
cases). However, it's exactly the sort of bug that could bite if one tried to
emulate DCOP with D-bus
[1] not sure whether anyone actually uses it.
More information about the kde-core-devel
mailing list