Coroutines vs. goroutines

[Brendan Tracey]

A group I'm in is discussing the merits of programming languages for a new project. I was hoping that someone could expand on the answer given in the FAQ (http://golang.org/doc/faq#goroutines)

Rob Pike at one point said something to the effect of "goroutines are not co-routines though they did influence the design". I think the FAQ explains what coroutines are, but it's not clear to me in that first paragraph where the transition between coroutines and goroutines happened. Is it in the introduction of the runtime  ("the programmer sees none of this")?

Secondly, the question mentions "unless they spend a lot of time in long-running system calls, they cost little more than the memory for the stack". I am thinking about using Go for an application that may reqiure such system calls. What are the pitfalls of which I need to be aware? I've used goroutines with long running system calls before and hadn't noticed any problems

[Ian Lance Taylor]

On Thu, Feb 20, 2014 at 2:25 PM, Brendan Tracey
<tracey....@gmail.com> wrote:
> A group I'm in is discussing the merits of programming languages for a new
> project. I was hoping that someone could expand on the answer given in the
> FAQ (http://golang.org/doc/faq#goroutines)
>
> Rob Pike at one point said something to the effect of "goroutines are not
> co-routines though they did influence the design". I think the FAQ explains
> what coroutines are, but it's not clear to me in that first paragraph where
> the transition between coroutines and goroutines happened. Is it in the
> introduction of the runtime ("the programmer sees none of this")?

None of these terms are precisely defined. That said, in a typical
implementation of coroutines, when a coroutine blocks in a system
call, that part of the program blocks. On the other hand, when a
goroutine blocks, the goroutine scheduler will automatically cause
another goroutine to start running. So that is a key difference
between coroutines and goroutines. Another key difference is that
goroutines have an unlimited stack.

> Secondly, the question mentions "unless they spend a lot of time in
> long-running system calls, they cost little more than the memory for the
> stack". I am thinking about using Go for an application that may reqiure
> such system calls. What are the pitfalls of which I need to be aware? I've
> used goroutines with long running system calls before and hadn't noticed any
> problems

I have to admit that I'm not sure what that sentence is trying to
say. Filed http://golang.org/issue/7373 .

Ian

[Rodrigo Kochenburger]

> Secondly, the question mentions "unless they spend a lot of time in
> long-running system calls, they cost little more than the memory for the
> stack". I am thinking about using Go for an application that may reqiure
> such system calls. What are the pitfalls of which I need to be aware? I've
> used goroutines with long running system calls before and hadn't noticed any
> problems

I have to admit that I'm not sure what that sentence is trying to
say.  Filed http://golang.org/issue/7373 .

Correct me if I'm wrong but I think what that means is that since when a goroutine is blocked in a syscall, it also blocks a thread, so if you have many goroutines waiting on a syscall you also have one thread per blocked goroutine which will use more resource than just the goroutine stack.