Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“DBus is seriously screwed up”

thread.gmane.org

Post reply on HN
Print view View original

91–100 of 209 posts

Re: “DBus is seriously screwed up”

#91

Post by the_mitsuhiko »

huhtenberg wrote: post #57
the_mitsuhiko wrote: post #53

Earlier quoted context omitted.

> It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.

Nothing obvious about it. If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?

> If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning.

Far from it. One of the core designs of kbus (which dbus cannot do because it's not in the kernel) is that you can seal the payload buffer from the sender so the receiver and use it safely concurrently without having to clone anything.

There is obviously a lot of general inefficiency in the userland libraries but not in the design of it.

Re: “DBus is seriously screwed up”

#92

Post by [deleted] »

huhtenberg wrote: post #57
the_mitsuhiko wrote: post #53

Earlier quoted context omitted.

> It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.

Nothing obvious about it. If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?

[deleted]

Re: “DBus is seriously screwed up”

#93

Post by byuu »

coldtea wrote: post #67
byuu wrote: post #43

Earlier quoted context omitted.

> DBUS seems like a solution looking for a problem: The majority of the time there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives. Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time…

> Indeed. I just use shm_open()+mmap(MAP_SHARED) and go about sharing my data between processes, and have had no problems whatsoever. Then throw in sem_open() so only one process is locking the data at a time. Wrap all that in a 2KB header and it's trivial to use in any project. Is that sarcasm, or you don't know what dbus is used for?

> Is that sarcasm, or you don't know what dbus is used for?

I know what it's used for in the desktop application space; but you might want to ask the authors of Xfce components like Mousepad that make their software rely on it for simple tasks like reusing an existing window when opening a file. Because I'd sure like to be able to run my Xfce desktop with D-Bus off in FreeBSD.

"D-Bus is a message bus system, a simple way for applications to talk to one another."

With shared memory (IPC) or sockets (RPC), applications can talk to each other.

Yes, D-Bus gives you an API interface for this (though I personally can't stand it); which apparently comes with tremendous overhead, if the linked article is to be believed.

Yes, with raw memory/sockets, you have to do the queue work yourself. But that's CS101 stuff; you shouldn't touch IPC if you can't implement a simple shared queue.

For most use cases, D-Bus is like using a jackhammer to nail in drywall.

"In addition to interprocess communication ... it makes it simple and reliable to code a "single instance" application or daemon"

Again, very easy with shared memory and a semaphore. If your attempt to open the semaphore fails, you create it and become the daemon. When the daemon closes, you delete the semaphore. When a second instance opens and connects to the semaphonre, and then shared memory, then it writes the command-line arguments into the queue, and the daemon handles it. Voila, "single instance" application or daemon.

"and to launch applications and daemons on demand when their services are needed"

And this would be a more complex use case that would be harder to solve. It's also a much less common use case. I don't really feel it's directly related to basic IPC, it's D-Bus trying to solve multiple problems at the same time.

I'd rather follow the Unix way and split that into a separate component, perhaps built on top of the IPC protocol.

Re: “DBus is seriously screwed up”

#94

Post by the_mitsuhiko »

coldtea wrote: post #64
the_mitsuhiko wrote: post #53

Earlier quoted context omitted.

> It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.

> You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive. The real problem is he doesn't give any data for volume/bandwidth processed in his case. I don't see why a "security policy driven message bus" would be more expensive than what he describes (unzipping, business rules encorcement, analyzing, etc).

> I don't see why a "security policy driven message bus" would be more expensive than what he describes (unzipping, business rules encorcement, analyzing, etc).

It was in comparison with an HTTP server. I did not read much about the mail thread but from what I can tell it essentially benchmarks the uninteresting part of DBUS which is the part that runs in userspace. That's old and definitely needs improvements, but not the design of it. In fact, the design of KDBUS or the DBUS dispatching core is from what I can tell quite intelligent and makes sense from a performance point of view.

Without a doubt there are a lot of old bells and whistles attached to DBUS which need rewriting.

Re: “DBus is seriously screwed up”

#95

Post by [deleted] »

coldtea wrote: post #64
the_mitsuhiko wrote: post #53

Earlier quoted context omitted.

> It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.

> You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive. The real problem is he doesn't give any data for volume/bandwidth processed in his case. I don't see why a "security policy driven message bus" would be more expensive than what he describes (unzipping, business rules encorcement, analyzing, etc).

[deleted]

Re: “DBus is seriously screwed up”

#96

Post by hp »

huhtenberg wrote: post #57
the_mitsuhiko wrote: post #53

Earlier quoted context omitted.

> It blows my mind how such a simple operation as passing messages from process to process can baloon to waste the measured half a million CPU cycles. People manage to have full-blown HTTP servers service a request with less than that. You're comparing a lightweight thing with a security policy driven message bus. Obviously the latter is going to be more expensive.

Nothing obvious about it. If you look at the Linus's trace, it's all heap and mutex operations. That's just sloppy internal design full of concurrency bottlenecks and lots of in-memory cloning. You certainly don't mean to imply that both are the only way to implement a "security policy driven message bus" software, do you?

the trace isn't dbus itself, it's a particular client program using the gdbus binding. The gdbus binding uses a lot of malloc and threads, and this particular client program is all blocking round trips.

Re: “DBus is seriously screwed up”

#97

Post by elwin »

bandrami wrote: post #26
castell wrote: post #5

> Since then I'm convinced that people who are inventing RPC solve non-existing problems. Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.) Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes. It's more like the concept of Component Object Model faile…

It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage. True, but the idea of the self-registering COM object eventually seemed to limp across the finish line. Anyways. "Two key kdbus developers" ( ahem ) have said that the entire kernel signal mechanism should be deprecated because it's "too brittle and complex". When…

Signals are too brittle and complex. That's why you have to read three whole manpages to figure out what happens if a process gets the same signal twice in rapid succession.

They are also un-Unixlike: they are used to communicate three or four different kinds of information, and they do most of them badly.

Re: “DBus is seriously screwed up”

#98

Post by efaref »

bandrami wrote: post #77
XorNot wrote: post #65

Earlier quoted context omitted.

Except they're not wrong. We have a potentially infinite set of signals and data we'd like to communicate to programs and a very limited set of signals to do it with. I mean apache uses sigwinch as an exit code!

We have a potentially infinite set of signals and data we'd like to communicate to programs Ah, I think I've identified your problem. Signals are for alerting programs to a specific (small) set of changes of external states. There's nothing "potentially infinite" there (frankly having 2 different SIGUSR's is generous). For transmitting arbitrary messages, Linux provides message queues, which are very nearly sockets (…

You answered it yourself. It lacks efficient multicast.

What dbus really needs is an efficient kernel-level capability-aware multicast IPC mechanism, and a total rewrite of the user-space daemon to not be rubbish.

All the user-space daemon needs to do is provide a registration point for other processes to find and connect to each other via (existing) unicast or (new) multicast mechanisms.

My initial thoughts were that kdbus /was/ that IPC mechanism, but it sounds like that might not actually be true.

Re: “DBus is seriously screwed up”

#99

Post by castell »

lclarkmichalek wrote: post #38
thezilch wrote: post #35

Earlier quoted context omitted.

Seems to be doing better than the speeds sited by the KDBUS thread -- https://www.techempower.com/benchmarks/#section=data-r10&tes...

The fact that one slow implementation is slower than another slow implementation says nothing.

> Naive REST (HTTP, JSON) isn't exactly known for its performance

Naïve XML isn't known for its performance either. JSON is usually faster to parse than XML.

While D-COM uses a binary protocol, it uses XML for its "Introspection Data Format". Objects instances may implement Introspect which returns an XML description of the object, including its interfaces (with signals and methods), objects below it in the object path tree, and its properties. Objects may be introspected at runtime, returning an XML string that describes the object. The same XML format may be used in other contexts as well, for example as an "IDL" for generating static language bindings.

More info: http://dbus.freedesktop.org/doc/dbus-specification.html

Re: “DBus is seriously screwed up”

#100

Post by anon4 »

mwfunk wrote: post #73
lmedinas wrote: post #12

Another great Linus quote: "The people who talk about how kdbus improves performance are just full of sh*t." http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...

As entertaining as it might be to people who are entertained by such things ("not me" would be an extreme understatement), it's pretty much exhibit A for Linus' inability to manage people in addition to code. It's embarrassing, honestly.

Well, as Eric put it

At this point the strongest possible language and the strongest possible push back are being used because everything else is routinely swept under the rug.

Post reply on HN