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 552017
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Finally!
by butters on Sun 10th Feb 2013 01:00 UTC in reply to "RE[3]: Finally!"
butters
Member since:
2005-07-08

In Go, goroutines are the fundamental execution units, which are scheduled on a thread pool of an appropriate size for the hardware, much like nginx. Goroutines interact using channels which exchange values of a type.

Channels may be bidirectional or unidirectional, and they may be buffered to accept a particular number of values before blocking the sending goroutines and unblocking the receiving goroutines.

When a goroutine is about to block, the runtime schedules any other unblocked goroutine on that thread rather than blocking the entire thread. When the I/O request is complete, the goroutine is unblocked and reinserted into the runqueue of goroutines.

Since you're already familiar with nginx, that should be enough to get the gist of goroutines and how the runtime might use AF-BUS to implement channels.

Reply Parent Score: 3