On Fri, Nov 25, 2016 at 10:51 PM Dave Cheney <d...@cheney.net> wrote:
> > Yes, goroutine switching occurs a known points; effectively where the > goroutine is blocked from proceeding; sending and receiving on channels (if > they are full/empty respectively), trying to acquire a locked mutex, and > performing IO. These operations happen frequently in a program that > interacts with others so things more or less work out. > > I was of the impression Go checks on function calls nowadays. Since you have to check the stack anyway, you can always piggyback on that routine if you want the system to schedule out the goroutine. Only checking on points-of-communication could lead to worse latency because a non-communicating goroutine is then able to tie up a processing core indefinitely, and delay garbage collection. Not checking inside for-loops puts the onus on the programmer to break such loops via function calls, but this is a far easier thing to handle from a programmer perspective when needed, and when not needed it could be argued it needlessly slows down the program. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
