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."
Thread beginning with comment 551977
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Finally!
by Alfman on Sat 9th Feb 2013 05:58 UTC in reply to "Finally!"
Alfman
Member since:
2011-01-28

butters,

Well, first of all let me state that I do share your enthusiasm for moving this sort of IPC into the kernel.


"In the beginning, there was select and poll. Then there was epoll. But their days may be numbered. It should be obvious that the socket is the one true UNIX abstraction for IPC."

I'm not sure if you meant exactly what you said here, but select/poll/epoll are complimentary mechanisms for using sockets, sockets don't supersede them. I've found that epoll is by far the most efficient way to handle many asynchronous sockets.


"This is the way it was always meant to be. We fork a bunch of small processes, each of which does one thing well, and hook them all together with read() and write()."

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...

Reply Parent Score: 7

RE[2]: Finally!
by butters on Sat 9th Feb 2013 23:29 in reply to "RE: Finally!"
butters Member since:
2005-07-08

I should have said "execution units" instead of processes. Obviously multithreading is an improvement over multiprocessing, and multiplexing coroutines on a non-blocking thread pool is an improvement over multithreading.

But an in-kernel message bus would still ease the implementation and accelerate the performance of a modern concurrent runtime platform such as Go, whose channel type would map nicely to AF_BUS.

Reply Parent Score: 4

RE[3]: Finally!
by Alfman on Sun 10th Feb 2013 00:23 in reply to "RE[2]: Finally!"
Alfman Member since:
2011-01-28

butters,

"I should have said 'execution units' instead of processes. Obviously multithreading is an improvement over multiprocessing, and multiplexing coroutines on a non-blocking thread pool is an improvement over multithreading."

Yea, multithreaded is a large improvement over multiprocess for efficiency. According to the next link, the minimum stack size is 16K.

http://stackoverflow.com/questions/12387828/what-is-the-maximum-num...

So there is still a lot of per-client overhead that cannot be eliminated in the blocking thread model. This is why I'm a huge fan of the nginx's type of concurrency model. If your not familiar with it, it uses a number of processes equal to the number of parallel cores. Each process on top of that uses an asynchronous mechanism like epoll. This means it can get full concurrency across CPUs and handle each client with asynchronous IO. Each client only uses as many resources (CPU and memory) without the overhead of any synchronization primitives used by threads.

I'm so happy with this model that I try to encourage others to adopt it, but often times implementations compromise the model (especially by using blocking file-IO, linux doesn't even support asynchronous non-blocking file-IO). So an application which makes heavy use of uncached file-IO will probably do better with more threads to prevent clients from blocking each other and the async loop becoming idle.

Anyways, my personal programming philosophy aside...


"But an in-kernel message bus would still ease the implementation and accelerate the performance of a modern concurrent runtime platform such as Go, whose channel type would map nicely to AF_BUS."

I'm afraid I haven't learned much about go yet, despite a suggestion that I should. I am interested, how would go incorporate a kernel bus into a language feature that ordinary go programs would use?

Reply Parent Score: 3

RE[2]: Finally!
by JAlexoid on Sun 10th Feb 2013 00:08 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

RE[3]: Finally!
by Alfman on Sun 10th Feb 2013 01:08 in reply to "RE[2]: Finally!"
Alfman Member since:
2011-01-28

JAlexoid,

"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."

In the past I've done the socket benchmarks myself, apache was just an example, feel free to substitute whatever example you like. Blocking socket IO implies using either multi-process or multi-threaded models, I hope that we can agree that the forking multi-process model is the least scalable.

There's nothing wrong with the multi-threaded blocking model, I don't critisize anyone for using it. However it does imply more memory/cpu overhead than the non-blocking model due to each client using it's own stack and the requirement of synchronization primitives that are usually unnecessary with the async model. Additionally the multithreaded solution does not increase concurrency over an asynchronous solution when the number of async handlers equals the number of cores, so right there you've got all the ingredients for async to come out ahead.

Mind you I think the difference is negligible when the number of concurrent users is low, but async really shines with many concurrent connections (10K+).

Reply Parent Score: 4