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 552098
To read all comments associated with this story, please click here.
RE[5]: Finally!
by Alfman on Mon 11th Feb 2013 01:12 UTC in reply to "RE[4]: Finally!"
Alfman
Member since:
2011-01-28

JAlexoid,

"Be all the fan you want, but you have to see it's limitations. It's great for stateless retrieval protocols. For everything else, it depends on the given case."

What would give you the impression that nonblocking async is poor when it comes to stateful IO? I'll give you that the models are rather different beasts when it comes to programming them. Windows programmers traditionally used async, unix ones traditionally used blocking io, so maybe there's a bit of religious animosity between the models. It's probably true that many programmers prefer dealing with sequential instructions over an event/callback oriented state machine, but still the two models really are equally expressive.

Reply Parent Score: 2