Not quite. Since 1.2, goroutines can yield on non-inlined function calls (in 1.1 it happens only on IO or on an explicit Gosched() call). A goroutine with no funcall or only inlined function calls will still block the scheduler (and the whole system if there's only one scheduler).
This tends not to be an issue in practice as you almost always have non-inlined function calls or short-executing loops. The one way in which this might be a problem is if you try and implement a spinlock, but there is no excuse for that given the go concurrency features.
> This tends not to be an issue in practice as you almost always have non-inlined function calls or short-executing loops.
Until it's an issue because somebody set up CPU-bound image processing, and then by lying you've set people up for failure and you've given them a huge blind spot once things start not working correctly.
:) I like that phrasing, it gets to the main result (you shouldnt ever worry about it) while still giving you the out that more leaks under the covers (in case you think this might be biting you.)
If you use libgreen in Rust, you don't even have the preemption at function calls, and it works OK. I agree that this isn't much of an issue in practice.
Not quite. Since 1.2, goroutines can yield on non-inlined function calls (in 1.1 it happens only on IO or on an explicit Gosched() call). A goroutine with no funcall or only inlined function calls will still block the scheduler (and the whole system if there's only one scheduler).