As a side note, I see sorokin's posts about DCOM, RPC and multi-threading:
> Probably some unique thread-id can be propagated through the calls. And if incoming call has the same thread-id as one of our outgoing call it is handled inside this outgoing call as in nested message loop, otherwise a new thread from thread pool is used. This will create an illusion that two processes share the same set of threads and it works well with mutexes.
I think he is slowly driving towards an actor like message passing thing like Erlang, Akka or Orleans without even realizing.
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
The link you posted has what I think is the right one:
The problem is that probably this code is not needed at all.
To me, 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.
To me, 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.
Then you need to read and reread and reread Havoc Pennington's posts on why he wrote d-bus in the first place:
D-Bus provides a service discovery system that lets you not only send messages to named endpoints, but also monitor whether there's something on the other end of the endpoint, and if necessary, request that it be started before you send the message in a non-racy fashion.
It also provides a common, typed, structured, discoverable, auditable serialization layer which is necessary for doing API-style IPC, and a benefit besides since when you "just use sockets" you have to do all the serialization and deserialization yourself, leading to possibly buggy code.
Oh, and it also does multicast, which no other commonly used Unix IPC can do.
People who say "I don't see the problem that d-bus solves" aren't looking hard enough and/or are ignorant of the issues of how software gets developed in a modern environment. D-bus solves many problems with IPC under Linux, and makes developers' lives a whole lot easier when they have to connect with other applications or services.
Is there a paper/article that discusses and categorizes the differences between IPC mechanism? Their pros and cons etc.
What mechanisms are there? What is used on Windows? OS X/iOS? QNX? BeOS? Android? Solaris? etc.
> 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. Wrap all that in a 2KB header and it's trivial to use in any project.
It would seem that modern computing is all about building abstractions on top of abstractions, to solve 'problems' nobody ever had. Nobody ever seems to consider the costs of such complexity (in terms of maintenance, understanding the system as a whole, attack vectors, etc.)
By all means, if you need a super complex system with tons of features like D-bus, great! But I am pretty confident that Mousepad (Xfce text editor) doesn't need D-bus just to open a text file in a new tab of an existing window.
>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.
I think what you're looking for is API standardization? If so, dbus does nothing more to help you than POSIX IPC, since each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects. Dbus is basically a way to do library calls across address spaces--it doesn't help me write programs that are loosely-coupled to one another.
No, looking for a standard message bus that works across applications.
I don't mind that "each dbus-speaking application can define arbitrary methods with arbitrary signatures and arbitrary side-effects", as that's the whole point.
If you don't know the API the application uses, you can't speak with it anyway. D-bus or not. If you want to talk to an entirely separate application, use a header for that application with its IPC/RPC functions defined in it. That's the same thing you'd do with or without D-bus.
All D-bus gets you is an official version of the header I spoke of. Along with so much overhead that you can't use it for any kind of media streaming, apparently. And now they want kdbus; and I definitely don't want their code in my BSD kernel.
there is no real reason to have such a complex layer of abstraction for IPC, when the system already provides much simpler alternatives
This. So many things that freedesktop does I just kind of look at and think "this just isn't remotely a problem I have, so I can't judge whether it 'solves' it or not."
It came out of the initial freedesktop project to improve interaction between KDE and Gnome.
KDE already had system called DCOP for internal use (allowed for instance Konqueror to be web browser, file manager and multi-pane FTP/SFTP client all at once).
But as with much of KDE it was created using C++. And Gnome is made using C.
So DBUS is something like a reimplementation of DCOP in C.
* AF_BUS, a new socket address family that provides a "generic" bus
* adding multicast and order guarantees to AF_UNIX sockets
None of these have the political traction that kdbus has. Kdbus, systemd, etc. get mainstreamed because they have top developers gunning for them being mainstreamed. The people on the sidelines going "but muh unix" are also-ran haters, nothing more. So let's just throw the switch and fry this sucker.
But, let's stop bitching and come up with alternatives, solutions, or closure. I'm tired of hearing about KDBUS (all love to gregkh) and DBUS.