Linked by Thom Holwerda on Sat 9th Feb 2013 02:04 UTC, submitted by ac
Linux "Both of these articles allude to the fact that I'm working on putting the D-Bus protocol into the kernel, in order to help achieve these larger goals of proper IPC for applications. And I'd like to confirm that yes, this is true, but it's not going to be D-Bus like you know it today. Our goal (and I use 'goal' in a very rough term, I have 8 pages of scribbled notes describing what we want to try to implement here), is to provide a reliable multicast and point-to-point messaging system for the kernel, that will work quickly and securely. On top of this kernel feature, we will try to provide a 'libdbus' interface that allows existing D-Bus users to work without ever knowing the D-Bus daemon was replaced on their system."
Permalink for comment 552011
To read all comments associated with this story, please click here.
RE[2]: Finally!
by JAlexoid on Sun 10th Feb 2013 00:08 UTC in reply to "RE: Finally!"
JAlexoid
Member since:
2009-05-19

It's true that multi-process blocking IO is the traditional unix way, and some people prefer that way of programming. But a big reason for phasing it out is because it scales very inefficiently compared to multi-threaded and async models.

As a popular example, take a look at the scalability differences for a traditional multi-process web server (apache MPM) versus modern asynchronous ones:

http://whisperdale.net/11-nginx-vs-cherokee-vs-apache-vs-lighttpd.h...


Quite a common mistake. Comparing async performance to performance of Apache. Those don't highlight the differences in scalability of non-blocking IO, but demonstrate that Apache is big.

Reply Parent Score: 3