Mill: Go-style concurrency in C
millc.org
millc.org
Lots of things just provide chans, which are fancy thread-safe queues and are fairly easy to implement. Getting select{} right is the tricky (and powerful) part.
About a week ago I released a library to access Go's channels and goroutines (as implemented by gccgo) from C: https://github.com/stefantalpalaru/golib
It has Go's runtime select.
In Communicating Sequential Processes, you only communicate via messages (C) & the processes (P) sequentially (S) run to completion.
Go is not CSP. It is fair to say it was inspired by CSP. Go has a preemptive scheduler, and passing shared memory references is idiomatic and at times unavoidable.
In fact, Go-the-implementation is only partially preemptive, I believe: in addition to calls into the runtime, calling any function can now be a scheduling event. But if you have a tight loop with no function calls (just arithmetic, perhaps), that goroutine will not yield control. A true preemptive scheduler would be able to take control from that goroutine.
[edit: hmm. Possibly I've mis-parsed that.]
I have a theory that there exists no software engineering term that is unambiguously understood by all language communities to be the same thing. If there is one, it won't be for long.
Another recent fun one: "Continuation". Used to mean something very specific in the programming language theory community, it is now nearly indistinguishable from "thread" in many communities.
Compare to state of affairs in medicine, as an example.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
CSP communication occurs by synchronising events between (possibly unnamed) processes. Each process offers events, and some events are only permitted to occur when every process in a synchronisation group offers them. Channels (which are a concept going back to CSP) are essentially families of events (so the set of events in.x for any x would also be referred to as the channel in).
The main difference between CSP and the languages that are sort of based on it (and this is a difference that predates Go by a long time -- it's visible in occam, for example) is that CSP events aren't directional or procedural like channels, they're just things that sort of happen (so they don't have to be written from one place and read in another -- they can occur with only one process running, or can be used to synchronise between more than two processes, or one process can restrict another by not offering events).
Communicating through named processes would be closer to the actor model than to CSP.
Though I'm kind of bummed that libthread is as obscure as it is...
I am as well. That's the coolest thing about Go imo, Go basically distills down a lot of the coolest stuff from Plan 9, and took it to the 'masses'. Edit; that just my impression, I'm not a Go user.
It would be very useful to have syntactic sugar over coroutines and channels in C. There are quiet a few coroutine libs around, but having it in the language would be compelling.
Basically it, I think. Go is the logical evolution of the Limbo language used to write native applications for the Inferno OS, itself evolving from Rob Pike's research with Alef and Newsqueak. The direct heritage spans at least a couple of decades, intermingled with the Plan 9 toolchain and interfaces.
Alternatively, can someone confirm/disconfirm that the ico's bad news?
EDIT: Looks like it doesn't like http://millc.org/main.css which is innocuous. >>shrugs<< looks like a false positive.
$ gcc -o test test.c mill.c
mill.c:221:13: error: conflicting types for 'wait'
static void wait(int fd, short events) {
^
In file included from /usr/include/stdlib.h:65:0,
from mill.c:33:
/usr/include/sys/wait.h:248:7: note: previous declaration of 'wait' was here
pid_t wait(int *) __DARWIN_ALIAS_C(wait);
^It's generally not a problem on x86, but in my experience for other platforms, it gets messy quickly.
It would be nice if a replacement or a "de-deprecated" was around.