On Wed, Jun 21, 2017 at 5:40 AM Ronald <yunthana...@gmail.com> wrote:
> Hi, I found when running this code below (play > <https://play.golang.org/p/XyxV_1f6Ri>): > > > You are looking at a property of a specific Go implementation, not a property of the language. Any system must define a set of "preemption points" at which you can switch out one process for another. Historically go only preempted on channel communication and (blocking) system calls. Later it also added preemption on function calls (it piggybacks on stack checks). Adding more preemption requires you to add checks inside loops so a loop eventually gets preempted, but the caveat is that this might slow you program down when you have a tight loop for which the compiler can prove no eventual bound. The current best workaround is to make sure that lengthy work periodically hits a preemption point some way or the other. Later versions of Go might solve this problem by adding those checks itself automatically to your programs to improve their latencies. Other concurrent languages use different methods: Erlang preempts like Go does currently, but since loops are implemented with recursion, you are sure to hit a preemption point every time you go round the loop. Haskell preempts on memory allocation and Haskell programs tend to allocate memory quite frequently. The exception is tight (fusioned) loop code on arrays. Go is doing a *far* better job here than almost every other programming language out there when it comes to fair scheduling. And there is a somewhat simple workaround: just add a function call occasionally depending on your required latency bound. -- 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.
