3 ms·
> coroutine void worker(const char *text) { At first I read 'goroutine' and thought something is wrong with my mind and that I have coded too much Go. But then
by JepZ 9y ago
> coroutine void worker(const char *text) {
At first I read 'goroutine' and thought something is wrong with my mind and that I have coded too much Go. But then I saw this:
> go(worker("Hello!"));
Now I am pretty sure someone got inspired by Golang ;-) Nice to see some backporting of Go features to C.
Note: That doesn't mean that Go is the only language that supports easy concurrent patterns, but that the creators of Go wanted to improve C and while not everybody agrees that all they have done are improvements, making concurrency easier most certainly is one.
- scadge 9y agoI think it's fair to say that Go was hardly the first language to implement the concept of coroutines[1]. Probably the only merit of Go here is the short and convenient name of the 'run' method. [1] https://en.wikipedia.org/wiki/Coroutine#Implementations https://en.wikipedia.org/wiki/Coroutine#Implementations
- teamhappy 9y ago> libmill was a project that aimed to copy Go's > concurrency model to C 1:1 [...] > libdill is a follow-up project that experiments with > structured concurrency and diverges from the Go model. http://libdill.org/documentation.html http://libdill.org/documentation.html
- rumcajz 9y agoI would say the main advantage is being able to pass couroutine arguments as if it was a simple function. In other coroutine implementations in C (e.g. libtask) you have to make a struct containing all the args and pass that to the run function.
- lucozade 9y agolibmill, the pre-cursor to libdill, was directly inspired by an implementation of nanomsg written in go (called mango I believe). Martin had struggled with the state machine approach he had been using and the coroutine approach of golang was a lot easier to reason about in practice. libdill was a development on libmill in two main ways: it was more idiomatically C and it supports structured concurrency. The latter is, in my opinion, very interesting. Martin has a blog post on it [0]. BTW I've got all this from following the nanomsg threads and reading Martin's blog. I'm not an active participant, so I may have some details wrong, but I think it's fairly accurate. [0] http://250bpm.com/blog:71 http://250bpm.com/blog:71
- akkartik 9y agoI'll add a link to the (to my mind) canonical articulation of why coroutines are superior to state machines: https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html I'll also add a shameless plug to my recent 'port' of this essay for a VM with first-class continuation support: http://akkartik.name/coroutines-in-mu http://akkartik.name/coroutines-in-mu