4 ms·

+5 for realizing that dbus-daemon is stupid because IPC is the kernel's job -10 for fixing it by putting dbus-daemon into the kernel To redeem yourself please

• FooBarWidget 16y ago
  How do you want to implement broadcasting without a daemon or some other intermediary? It's called, you know, dbus.
  • humbledrone 16y ago
    An intermediary-free broadcast system can easily be implemented by setting up a memory segment that is shared between processes. One process writes to the memory segment, and many other processes can read from it (usually after being signaled to do so via a condition variable).
    • FooBarWidget 16y ago
      I dispute the notion that it is "easy" and the implicit notion that it's better than a system with an intermediary. * Inter-process condition variables are not supported on all operating systems. The next best thing would be sockets or message queues but these don't support broadcasting. * Having multiple processes read and modify the same memory segment requires some kind of locking. Inter-process locks are expensive (or at least, more expensive than local-process locks) on most operating systems. On Linux a lock file is more expensive than a POSIX mutex. This can really kill performance compared to a system in which sockets are used to communicate with an intermediary and other bus listeners. * Any process can corrupt the shared memory segment and screw up the state of all other processes that use it. * With shared memory it becomes impossible to properly detect dead processes. Suppose a process connects to the bus and increases some kind of reference counter in the shared memory. If the process crash without properly decrementing the counter then other processes would never know that the number of processes would have gone down. You can add checks like checking whether other PIDs still exist but this is unreliable and kills performance. If you can prove me wrong, that'd be great, because I'm looking for an IPC mechanism that's faster than Unix domain sockets. I tried inventing my own with shared memory and inter-process locks and couldn't get it nearly as fast as sockets.
      • humbledrone 16y ago
        I didn't mean to implicate that using shared memory would be better than an intermediary. I do still think that implementing a simple broadcast mechanism with shared memory is fairly easy, provided that you have access to inter-process condition variables. If not, things do get a lot more complicated (e.g. polling, yuck). I don't think I can prove you wrong, per se. I do have a suggestion, though: have you tried using shared memory for data transfer, and using a UNIX socket for synchronization? Only a tiny bit of data would have to be transferred over the UNIX socket (shared memory address to read from, etc), and the rest of the data could be read via the shared memory.
      • humbledrone 16y ago
        Another thing you might consider: lock free data structures. This C library for exactly that just hit the front page: http://www.liblfds.org/ http://www.liblfds.org/
  • wmf 16y ago
    How much D-Bus traffic is broadcast and how much is point-to-point?
    • nitrogen 16y ago
      I imagine a lot of D-Bus traffic is at least multicast, such as window state notifications, media player status notifications, etc.
  • sandGorgon 16y ago
    I have a question - with systemd [http://www.freedesktop.org/wiki/Software/systemd http://www.freedesktop.org/wiki/Software/systemd], do you still need a daemonized message bus ? OSX's launchd, creates listening sockets and when it receives a connection, it starts the service and hands over the socket to the service. Given such a scenario, can you not simply work with plain-jane IPC ?
    • FooBarWidget 16y ago
      I don't see how that can be compared with a message bus. They do different things.
  • kijiki 16y ago
    a) netlink socket. b) multicast.