This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the unix category.
Last Updated: 2024-11-23
It facilitates interprocess communication between applications (either two copies of the same application or different applications altogether)
Example: There's this program called terminator (a rough analogy would be something
that lets you manage terminal space, like screen or iterm). Someone runs
$ terminator &
$ terminator --new-tab &
The first command opens a new window. The second command opens a new tab in the first window -- i.e. no long-lasting new process is started.
How does it do this? Because the second process is using dbus to find the first
process, asking it to open a new tab, then quitting.
bus = DBus::SystemBus.instance
# Access the service by name
rhythm_box_service = bus.service("org.gnome.Rhythmbox")
# Get "reference" to a remote function in the (remote) rhythm box service
rb_player = rhythm_box_service.object("/org/gnome/Rhythmbox/Player")
# Execute it. Note that is is async
rb_player.introspect
# You can also respond to a remote signal
rb_player.on_signal("elapsedChanged") do |data|
puts data
end
Sockets also do Inter Process Communication (IPC) - e.g. process Z opens
/var/run/z.socket and process L reads/writes to it. The standard way of doing
this is clunky and expects one process to be running with its socket before the
other is loaded (however this need not be to so - see SystemD Socket Optimization)
Now what if you want to have communication between two programs' processes where one program didn't exist when the other was written. D-Bus can solve this issue by providing protocols and service discovery and information exchange. That way an interface is worked with rather than a pre-existing socket.
Modern daemons on Linux tend to provide services via D-Bus instead of plain AF_UNIX sockets.