RFC: DBUS & KDE 4

[Maks Orlovich]

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.